Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : Chris Thomasson
Date : Thu Sep 29 2005 11:34 pm

> You misunderstand me; I talked about the producer/consumer-pattern
> with the usual mutex-locks (which cause a kernel-intervention only on
> collisions).

Yes. However, they also execute an atomic operation and a nasty StoreLoad 
style membar for the lock and unlock, contention or not. IMO, these types of 
operations are very expensive for modern processors to execute. Especially 
if they have to lock the bus...




> In this case, the lock is held an extremely short inter-
> val and the processing of the data taken from the queue lasts at least
> some thousand times longer than the dequeue-process. So the likehood
> of a collision is that short:

Actually, to further enhance your point, there is an efficient lock-based 
queue out there that is simply guaranteed to get absolutely no "collisions" 
between a producer and consumer (can show you pseudo-code if you want).


> that there's no need for lock-free processing?

Well, the only thing that a lock-free queue would buy you here, is reduced 
overhead wrt atomic operations and membars.




>> 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.
>
> In nearly every case this does not reduce the performance because
> enqueuing an dequeuing are only a very tiny part of the whole pro-
> cessing in almost any case.

Granted. However, imho, I still think that the ability to remove atomic 
operations and membars from producer/consumer systems and database searches 
is going to gradually become more and more important...

.