Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : Maciej Sobczak
Date : Tue Jun 07 2005 06:30 pm


This reply applies equally to the post of Mr. Butenhof.

David Schwartz wrote:

>     You should not design your code around optimizations that some pthreads 
> implementations have and some do not.

That's true.

The two scenarios might be comparable in terms of performance only when 
the optimization (wait morph) is present.

>     The purity argument is just misguided. Even if you signal something 
> that's true at the time you signal it, it may not be true at the time the 
> signal is noticed.

Which indeed shows that the "purity" is a matter of perspective. Thanks 
for pointing this out.


>     The first scenario tends to result in extra context switches. You should 
> not architect around optimizations that a pthreads library may or may not 
> have.

Interestingly, the scoped lock pattern (realized with the RAII idiom in 
C++ and native in languages that support the "synchronized" keyword or 
alike) promotes exactly this way of working:

{
     scoped_lock lock(mtx);

     // do something ...
     condvar.signal();
}

Above, condvar is signalled before the mutex gets unlocked.
Doing otherwise would require something like this:

{
     scoped_lock lock(mtx);

     // do something ...
}
condvar.signal();

which can become ugly in the outermost block (like when the block is the 
whole funcion body).

What about this?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

.