Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : David Schwartz
Date : Tue Jun 07 2005 02:46 pm


"Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
news:42a60045$1_1@news.bluewin.ch...

> The only problem (again about purity - I know, it's a matter of 
> perspective ;) ) is the fact that signalling is logically related to the 
> stuff that I did while holding the lock (after all, I want to signal that 
> I did that stuff). The scope cleanly shows this relationship:
>
> {
>     scoped_lock lock(mtx);
>     // ...
>     cond.signal();
> }
>
> Above, everything that is inside the block is logically related and exists 
> together. Of course, the scope does not contain any unrelated stuff and it 
> can be artificially introduced as nested scope inside another block.
>
> If we try to signal after unlocking the mutex, then the logical 
> relationship between the stuff that requires locking and signalling that 
> it was actually done, is "lost" in the source code:
>
> {
>     scoped_lock lock(mtx);
>     // ...
> }
> cond.signal();
>
> Above, it is not clear that signalling is related to what was done inside 
> the block.
>
> I understand the performance issue, 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();
}

    DS

.