Re: [boost] Boost.Threads Locking Delima

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-05-18 10:04:48

At Friday 2002/05/17 09:42, you wrote:
>From: "William E. Kempf" <williamkempf_at_[hidden]>
> >
> > This doesn't cause you to not know the exact lifetime of the lock... it
>just
> > means the programmer had better understand the rules of move semantics.
>In
> > other words, as long as you pay attention to how move semantics work this
>is
> > a very deterministic mechanism for lock management, as opposed to say how
> > shared_ptr works.
>
>shared_ptr is completely deterministic, too. If you pay attention, you'll
>never go wrong. The problem is that it's more flexible, and a shared lock
>would probably be easier to misuse if you don't pay attention.

To use an analogy that's been in use for decades to save human lives:
At large construction sites where various electrical work  will be going 
on, there is a shutoff which can be locked _open_ simply by putting a 
common padlock on it.  The "hole" for the padlock to secure is large enough 
for many locks.  When an electrician comes to work and needs the power 
killed, s/he simply adds his/her personal lock.  When done, one removes 
one's own lock and leaves.  The power cannot be restored until ALL the 
locks are gone.
Certainly this model can be explained even to a newbie (especially if 
they've ever managed to be on the receiving end of an electrical shock) and 
is reliable, and considered foolproof enough to have lives depend on 
it.  Modelling it for use in multi-threading/tasking seems natural to me.
Note this _may_ imply a requirement that more than one thread may need 
access to the same "hole" and may necessitate a _real_ semaphore (i.e. 
signalable by a thread other than it's "owner") rather than "thread safe" 
mutexes.

> > If you know the rules of move semantics this isn't a case where you'd lose
> > the lock but didn't expect to.  The problem is, as with auto_ptr, newbies
> > don't understand the rules of move semantics so *they* are surprised.
>
>The problem is that, at present, we don't have a language construct with
>which to express move semantics. std::auto_ptr uses pass by value, and this
>is what confuses newbies and veterans alike. Pass by value is not supposed
>to alter the original.
>
>Do we need to transfer locks into functions? Perhaps locks need an even more
>restricted version of 'move semantics', that supports return by value only.

My above analogy to locking the electrical power off _may_ show that you 
not only need to transfer locks to functions, but, I believe, that you may 
need to either share or transfer them to other 
threads/processes/tasks/whatever.  The analogy for transfer is, of course, 
handing the key to _your_ lock to someone else.

>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"