Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : Oliver S.
Date : Thu Sep 29 2005 05:44 pm

> This would be true for the Michael-and-Scott queue algorithm;
> its loaded with cache thrashing CAS-loops.

You misunderstand me; I talked about the producer/consumer-pattern
with the usual mutex-locks (which cause a kernel-intervention only on
collisions). 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, that there's no need for lock-free pro-
cessing?
 
> So, "certain types" of lock-free queues are useful
> for high-performance cpu-to-cpu communications.

I doubt that there's a noteworthy need for this kind of high-perfor-
mance cpu-to-cpu communications because of the usual code patterns
mentioned above. Please tell me only a single case in which the en-
queuing or deqeuing with usual mutexes takes a noteworthy time in
relation to the time taken to process the dequeued items afterwards.
And even if we would have this unlikely case where this might happen
and we would have a high collision-rate with usual mutexes; then we
would simply push a buch of items in one enqueuing-step and pop a
comparable bunch of items in one dequeuing-step and the whole pro-
blem vanishes.

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

.