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 pop. Brian
