Re: [boost] Boost.Threads Locking Delima

From: Eric D Crahen (crahen_at_[hidden])
Date: 2002-05-19 08:00:17

I just wanted to clarify a couple things from my last post that might
have caused confusion.

>   T3: turn on power (T1 hasn't finished adding its lock,
>      and its already past the point where it would wait for the power
>      to turn off.)

I'm going with the analogy of the worker looking at the power supply
to see if there are locks on it or not.

>  void doSomething() {
>
>    Guard<Mutex> g(lock);
>    // "ownership" implicity transfered to the caller
>
>  }

Here, I'm talking about transfering the "ownership" to the client for the
duration of the call - which is exactly how long its needed. It can get
more fine grained by just using smaller scopes for the guard within this
function. The idea here is that this lock is guarding some resource,
transfering "ownership" explicitily to the calling function, and possible
from that function to another function (and so on) and finally back again
isn't necessary.

Its far more difficult to create a resource class that is guarded by
this lock if its "ownership" is transfered out where the resource is
no longer in control of that ownership. The resource class couldn't be
sure the client who received "ownership" has given it back (it could be
transfered to a misbehaved function, or something that doesn't let the
"ownership" go). It's harder to debug that and the resource class itself
can't make any garuntees about its thread-safety on its own because the
clients of the resource are really in charge of the sycnrhonization when
this happens.

- Eric
http://www.cse.buffalo.edu/~crahen