Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : Torsten Robitzki
Date : Wed Jun 08 2005 01:06 am

Maciej Sobczak wrote:
> David Schwartz wrote:
> 
>>> now the question is about what programming style we should promote to 
>>> benefit from potential performance gain without surprising those who 
>>> happen to read the code.
>>
>>
>>     Easy.
>>
>> {
>>  scoped_lock h(mutex, condvar);
>>  // do stuff
>>  h.Unlock();
>>  h.Signal();
>> }
> 
> 
> Which completely defeats the purpose of scoped_lock.

Not realy. I think the main purpose of the scoped_lock is to make sure 
that the mutex is unlocked when the scoped is left, for what ever 
reason. The unlock() is done via the scoped_lock, so scoped_lock knows 
if the mutex have to be release in the destructor or not.

> The above can be written in the following way with the same set of pros 
> and cons:
> 
> {
>     mutex.lock();
>     // do stuff
>     mutex.unlock();
>     condvar.signal();
> }

I would rewrite it like this:

{
   mutex.lock();
   bool locked = true;

   try {
     // do stuff
     mutex.unlock();
     locked = false;
     condvar.signal();
   }
   catch (...)
   {
     if ( locked ) mutex.unlock();
     throw;
   }
}

> 
> But I take the oppostunity to push your idea in the following direction:
> 
> {
>     scoped_signalling_lock lock(mutex, condvar);
>     // do stuff
> }
> 
> The destructor of lock is supposed to do "the right thing".
> 

Sounds cool to me ;-) I had the idea to let the signal function release 
the mutex too, but that might cause a lot of bugs. In detail, your idea 
could hide the implementation detail if it's faster to first release the 
mutex and than signal the cond var or the other way round.

regards
Torsten

.