Re: boost::mutex::scoped_lock conventions

From: Mark Sizer (yg-boost-users_at_[hidden])
Date: 2003-05-13 13:43:16

The hypothetical is easy enough:

void myclass::doSomething()
{
   scoped_lock lockData( _mutexData );
   <do something using the data>
}

After two years and three developers:

void myclass::doSomething()
{
   scoped_lock lockData( _mutexData );
   <do the original thing that needed the lock>

   <do all sorts of additional stuff not needing lock>
}

Of course we all know that no programmer would ever be so lazy as to 
modify code with which he was not completely familiar (I REALLY need 
thread IDs! - sound eerily familiar? [btw: TSS is working great.]). No 
one would ever make one method do several different things, either. All 
code is kept optimally factored over years of development <chortle>.

In an ideal world, unlocking is rarely necessary. In the real world, I 
think it helps define the developer's intent. At the very least the next 
programmer is presented with the obvious choice of putting the new code 
before or after the "unlock". He can still do it wrong, but it has to be 
concious choice.

Haven't you ever tracked down this bug (usually introduced by those who 
think indentation is for wimps):
if ( <condition> )
{
   <do true>
}
else
   <do false>

that becomes:

if ( <condition> )
{
   <do true>
}
else
   <do false>
   <do more false> // oops!

Same pattern, different situation. If I ever get around to creating a 
language, it will be indent sensitive. Screw the punctuation ('{', 
'begin', '(', etc...).

Thanks,
   - Mark

P.S. On the same note, does anyone indent inside locks (I don't)?

William E. Kempf wrote:

> Mark Sizer said:
> 
>>Is there a convention about whether or not to explicitly call .unlock()?
>>
>>In the case where everything to the end of the scope should be locked,
>>there is no NEED to do it, but isn't it a bit sloppy to leave locks
>>locked?
>>
> 
> Certainly not.  That's the purpose of the RAII idiom.
> 
> 
>>Much like not using braces on one-line 'if' statements, it could cause
>>maintenance problems later.
>>
> 
> I wouldn't think so, but maybe you have a use case to share where you
> think it could?
> 
>