Subj : Re: Lock Free -- where to start To : comp.programming.threads From : David Hopwood Date : Thu Sep 29 2005 04:04 pm Chris Thomasson wrote: >>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; it's 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... Right, but isn't this missing the point of David Schwartz's comments? This newsgroup has had *many* threads with the following pattern: - someone asks how to solve a problem. Typically it's clear from this post that the poster has relatively little experience with concurrent programming in general. - one of the usual suspects suggests "using lock-free techniques". - the thread wanders off into esoterica about how to implement stuff at a completely disjoint level of abstraction to the original question. To some extent this is just par for the Usenet course; OTOH, this group does seem to have a particular collective obsession with lock-free at the moment. Some of us are concerned that newbies are getting, at best unfollowable, and sometimes just plain bad advice as a result. -- David Hopwood .