Subj : Re: pthread_cond_signal() semantics
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Sun Jan 09 2005 11:16 pm

Marcin 'Qrczak' Kowalczyk wrote:

> Giancarlo Niccolai <searchforme@ingoogle.com> writes:
> 
>> (unless you are using FIFO mutexes which are often provided as
>> extensions, but that many of us here disapprove).
> 
> Do "FIFO mutexes" mean that they guarantee that threads will be able
> to lock them in the order of arrival? If so, why is it disapproved?
> I guess you mean that it's bad to rely on such behavior, but it's
> not bad to actually provide it? What guarantees do non-FIFO mutexes
> provide about the order of locking - just lack of starvation?
> 

I am here arguing NOT against mutexes that guarantee that the first arriving
will be the first able to gain the lock (sorry for the semantic
imprecision). Implementations like that may or may not loose efficiency;
generally it is just an assumption you can't do, as efficiency often
advises against them, and there are programming techniques that prevent
starvation much better than fifo mutexes. So fifo mutexes may not be evil,
I am not talking against them, just I think that they offer nothing (as a
fair mutex achieving is something a well built application DOES NOT NEED),
and are costly for the nothing they offer.

I am talking against implementations that wake up waiting threads as soon as
the mutex they are waiting for is freed.

It is bad to provide it because mutex HAVE to be EXTREMELY fast in the fast
path, that is, where there is no contention. Also, it is EVIL because mutex
lock scope MUST be no longer than accessing and eventually changing the
data they protect; using mutex lock longer than a few opcodes is not
considered good. Many "bad things" may happen in the meanwhile, and as
mutex are the lightest possible sync primitive, they do no provide recovery
mechanisms as the condition variable does.

A yielding free mutex encourages to write code that waits for it to be free
again, which is NOT the reason why mutex are there. They are there to
ensure visibility and consistence of the region of memory you are currently
accessing, and not to wait for something to happen.

Also, a FIFO mutex implementing yield of the freeing thread would force your
thread to be swapped out if there is another thread contending the mutex,
but this is not a good idea. When you release a mutex, you just want to say
that you are done with some shared data, and NOT that you are done with
your timeslice. I.e. :

Lock()
mangle_data...
unlock()
read( private_data )

You are going to block on read, or you may do so. Being forced to drop the
timeslice at the unlock just to regain it and redrop it again is quite
inefficient.

If you want a fifo waiting structure, you can do it quite easily with a
non-fifo mutex and a condition, and the resulting code will be clearer and
surely more powerful (i.e. you will be allowed to do something SAFELY in
your wake-up turn). If you want the signaling thread to give up its
timeslice, you can do it explicitly or you can use system I/O as wait
points so that, if there is no data incoming, the other threads are
transparently able to advance.

So, as it is useless to provide things whose usage is sub-optimal (at best),
i would hint to stay away from yielding free mutex.

Gian.

.