Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : Charles Bryant
Date : Wed Aug 03 2005 12:16 am

In article <87iryoufsz.fsf@qrnik.zagroda>,
Marcin 'Qrczak' Kowalczyk  <qrczak@knm.org.pl> wrote:
>Charles Bryant <n519629998.ch@chch.demon.co.uk> writes:
>
>> However, it would be wrong to assume that, for example, an atomic
>> increment operation must be faster than a lock/increment/unlock
>> sequence, when it might be slower.
>
>Well, on a sensible implementation it will not be slower because it
>can be implemented by this.

I can imagine a reasonable system where it is slower. Such a system would
have hardware support for mutex lock and unlock operations, but no support
for any other atomic operations. An atomic increment operation which
could operate on any arbitrary integer, inc(x), would be implemented
as lock(mutex); x++; unlock(mutex). The problem would be what mutex to
use. Since the operation must work on any arbitrary integer, we can't
require the integer be in a structure with a mutex, so we would have to
use a single global mutex for all atomic increments (and, indeed, for all
other operations that are to be mutually atomic). This would execute at
the same speed as a normal lock(x.mx); x.val++; unlock(x.mx) sequence,
except when different threads wanted to increment unrelated integers at
the same time, when it would force one thread to wait unnecessarily.

.