|
Boost : |
Subject: Re: [boost] [threads] adopt_lock_t question
From: Jens Finkhäuser (jens_at_[hidden])
Date: 2008-11-03 05:26:54
Hi!
On Mon, Nov 03, 2008 at 08:00:08AM +0000, Anthony Williams wrote:
> Jens FinkhÃâ¬user <jens_at_[hidden]> writes:
>
> > Hi!
> >
> > I've come across something that puzzles me. I've got code that,
> > condensed to relevant parts, looks like this:
> >
> > recursive_mutex m;
> > lock_guard<recursive_mutex> l1(m);
> > lock_guard<recursive_mutex> l2(m, adopt_lock_t());
>
> That is an error. adopt_lock_t means that l2 takes ownership of the
> already-locked mutex (i.e. doesn't lock it again), but it doesn't
> force l1 to relinquish ownership, so both l2 and l1 think they own the
> one and only lock. When l2 is destroyed it will unlock the mutex, and
> then when l1 is destroyed it will unlock the mutex AGAIN, which is
> undefined behaviour because it doesn't own the mutex at this point.
>
> <snip/>
Thanks for your reply. I understand your argument, and what the code
*does*, just not the reasoning: how then is adopt_lock_t *supposed* to
work? It's not as if you can tell lock_guard to relinquish ownership of
a mutex.
If there is no need to adopt a mutex because there's only one lock
in the code, adopt_lock_t is superfluous. If there are two locks
involved, you'll always run into an issue where one lock gets to
unlock the mutex first - and the other one fails.
I've tried to find the standard proposal for this, and only found
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm
Unfortunately, that page doesn't shed much light on adopt_lock_t's
intended usage either. As it stands, the whole thing only makes sense
if you assume that you've locked the internal, operating system
specific mutex object with an operating system specific function prior
to using adopt_lock_t... but that doesn't seem reasonable either.
If someone could point me to documentation that details how
adopt_lock_t is intended to be used (or give an example), that'd be
helpful!
Jens
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk