Re: [Pan-devel] Race condition in queue.c::queue_run_what_we_can()

[Calin A. Culianu]

On Mon, 31 May 2004, K. Haley wrote:

> Calin A. Culianu wrote:
> 
> >Is there a reason for omitting this mutex lock/unlock?
> >
> >If it turns out locking isn't a bad idea (which I would argue it isn't),
> >how do I go about submitting this sourcecode change to the cvs tree?  
> >Should I just send a patch to this mailing list?  Does anyone want to
> >review this change?  I think it's a worthwhile stability fix..
> >  
> >
> The best thing to do is to submit a bug report to 
> http://bugzilla.gnome.org .  You can then attach your patch to the 
> report so it won't get lost.  If you want, you can post a message here 
> with a link to the report for anyone interested.  Whether or not it gets 
> applied is up to the devs.
> 
> 

Well after groking the source some more it seems the mutex is omitted as a
performance optimization.  Basically one can get away with omitting a
mutex lock/unlock calls during reading, but only from within the queue
processing thread.  This is because the queue processing thread is the
only thread that modifies/writes to the queue, and so when it is reading
the queue it knows that nothing else can be writing to it (since it is the
only writer).  It does use a mutex, though when it writes to the queue (to
avoid clashes with readers in other threads).

This makes sense and it won't create a race condition.  So my patch to
introduce an RW lock into the mix is useless, basically, because it makes
things more complex and wasteful of a few CPU cycles/context switches.


-Calin