Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : Chris Thomasson
Date : Wed Sep 28 2005 10:13 pm

> I think what David means, is that lock-free is over-emphasized and I
> must agree on that. With producer/consumer-patterns typical in server
> -applications, intervals where queues are locked are extremely short
> (in the best case only a pointer is fetched from a queue) and the
> processing-intervals when a dequeued item is processed at least some
> thousand times higher. So there's no real need for lock-free queues.

This would be true for the Michael-and-Scott queue algorithm; its loaded 
with cache thrashing CAS-loops. However, "zero-overhead" loopless 
single-producer/consumer queues are ideal for various distributed 
producer/consumer systems. IMHO, a thread that is bound to a particular cpu 
core, and wants to send a message to another thread that is bound to a 
"nearby core", should use a method that has no atomic operations; just a 
StoreStore for producers, and a data-dependant load for the consumers should 
be enough. I have a feeling that scaleable designs for the new multi-core 
stuff that's coming out will be NUMA-like...


The ability to remove atomic operations and nasty memory barriers from a 
distributed messaging system is a plus. As we all know, multi-processor 
systems do not take kindly to these types of instructions...

;)


So, "certain types" of lock-free queues are useful for high-performance 
cpu-to-cpu communications. Especially, when a core on one cpu has to send a 
message to a core on another cpu; atomic operations and membars would 
greatly reduce performance.




> Lock-free lifo-pools may make sense for memory-allocators, but good
> allocators magage thread-local pools so this need is minimized. And
> if you need maximum performance on memory-allocation, you manage your
> own pools.
> Lock-free processing may look fascinating, but primarily superfluous.

They also work well as solutions to the reader/writer problem. They can be 
used to remove the need for atomic operations and StoreLoad style memory 
barriers; imho, that's not really superfluous.

.