Re: thread lock/unlock example

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-14 09:16:56

--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> hi,
> I find an example where lock and unlock can be useful.
> suppose we'd like to protect a with m, but we don't would like to 
protect f
> (suppose it's long) and have the following code (if we have 
lock/unlock on 
> mutex).
> -----------
> {
>   boost::lock lock(m);
>   for (int i = a.get(); i < 10; a.next())
>   {
>     <some code>
>     m.unlock()
>     f();
>     m.lock();
>     <some code>
>   }
> }
> -----------
> without lock/unlock is looks like:
> -----------
> {
>   {
>     boost::lock lock(m);
>     int i = a.get();
>   }
>   while (i < 10)
>   {
>     <some code>
>     f();
>     <some code>
>     {
>       boost::lock lock(m);
>       a.next();
>       i = a.get();
>     }
>   }
> }
> -----------
> IMHO the first version is more simple clear and easier to read and 
understand.

Purely opinion.  Personally, I don't agree.

In any event this example likely leads to a race condition!  f() may 
modify a in a way that will invalidate the call to next()!  
(Arguments that it doesn't don't hold water with me, since later 
maintenance may change that.)

There are numerous ways to refactor this example, and it really needs 
refactoring.  Probably the safest solution is to take a hint from 
Java here and "enumerate" a by taking a (thread safe) snapshot of it 
in a locally controlled copy which can be safely iterated over, even 
if a were to be modified by f().

My point?  Writing thread safe code is very difficult, and your 
attempt to show an example of why lock/unlock might be useful helps 
to illustrate this fact.  With out the lock/unlock a programmer is 
more likely to think about and analyze the problem for more 
appropriate solutions before jumping to a lock/unlock idiom that 
results in race conditions or even deadlocks.  And again, if you 
*must* do this you still can, using constructs such as the 
unsafe_lock<> I posted.

Sorry, you've not convinced me to expose the lock/unlock on the Mutex 
concept.

> create the lock on the heap can't help here.

And why not?

Bill Kempf