apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker fdqueue.c
Date Sat, 18 Jan 2003 17:47:05 GMT
On Mon, 2003-01-13 at 12:21, Greg Ames wrote:
> Brian Pane wrote:

> > I'm planning on spinning around the CAS; i.e., retry if the
> > CAS fails due to a collision with another thread.  The queue_info
> > synchronization, which uses that same technique, seems to be
> > working well in practice.
> no...we're cool if the CAS fails; the problem is that sometimes it doesn't fail 
> when you wish it would.
> thread 1 prepares to pop A off the list and picks up its next pointer to B, then 
> gets interrupted/swapped out/whatever.
> other threads really pop A off the list, pop B off the list and free it, then 
> push A back on the list with A's next pointer now pointing at C.
> thread 1 wakes back up and uses CAS to compare for A and swap with B.  The CAS 
> succeeds on most architectures, because the head contains a pointer to A once 
> again.  This corrupts the head to point to B which has been freed.  The problem 
> is that A's next pointer had been updated, and a straightforward CAS on a single 
> word can't tell the difference between a pointer to old A and a pointer to new 
> improved A.
> I did look at the queue_info pop and decided it must be single threaded for a 
> given pool/qi combo, because it is driven as a pool cleanup and if that wasn't 
> single threaded already, the apr pool destroy code would go nuts.  I hope that 
> assessment is correct.

You're right; the queue_info code is safe because only a single thread
pops from that queue.  But for the reason you noted, I can't safely use
the same technique for the fd queue, from which multiple threads can


View raw message