3ed
Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : David Hopwood
Date : Tue Oct 04 2005 05:20 pm

Sergey P. Derevyago wrote:
> David Schwartz wrote:
> 
>>    But worse, in most realistic cases, lock free tremendously *reduce*
>>performance. The myth is that locks are expensive. The truth is that
>>*contention* is expensive. Lock free algorithms allow code that is
>>contending to run in parallel. Locks allow other code to run that probably
>>won't contend.
> 
> 	Moreover, some "lock free papers" define the "lock free" term in such a way
> that old good spin _locks_ become lock free synchronization primitives!

You're probably confusing a statement about the *implementation* of the lock with
a statement about the lock itself. Of course the implementation of a lock will
be lock-free (unless one kind of lock is being implemented in terms of another).
It won't be wait-free, though.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

.

0