Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : Maciej Sobczak
Date : Wed Jun 08 2005 09:28 am

David Schwartz wrote:

>>>{
>>> scoped_lock h(mutex, condvar);
>>> // do stuff
>>> h.Unlock();
>>> h.Signal();
>>>}
>>
>>Which completely defeats the purpose of scoped_lock.
> 
>     No, it doesn't. The purpose of a scoped_lock is so that you do not have 
> to put 'Unlock' calls before every 'return' and you can easily see where the 
> lock is held and where it is not held. This preserves those features.

OK. When I saw the explicit call to unlock above, I thought that you 
wanted to make it explicit all the time, as if the scoped_lock had no 
automatism built in. Later example was written based on this assumption.

>>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".
> 
>     Yes, so long as you have a function like 'signal' the causes the lock to 
> automatically signal after it's released.

You mean - a signal function of the lock with the semantic that there is 
no signalling if this function was not called?

{
     scoped_signalling_lock slock(mutex, condvar);
     // do stuff

} // implicit unlock, no signal

{
     scoped_signalling_lock slock(mutex, condvar);
     // do stuff

     slock.signal();

} // implicit unlock and signal

Looks good to me, especially in the context of possible exceptions 
flying out of "do stuff" (or just short-cut returns), when unlocking 
still makes sense while signalling would be needless - nothing to do at 
the waiter side, with appropriately high exception guarantees of "do 
stuff". This reminds me of similar idiom used to handle database 
transactions.

Of course, some flag given when the lock is constructed (or passed to 
the signal function or just two signal functions) to differentiate 
between single signal and broadcast would help as well.

What I like in this is that the logical relationship between condvar and 
the "do stuff" is preserved (so I have the "purity"), not only in terms 
of source code layout, but (most importantly) in terms of binding 
everything together with a single manager object.

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

.