Subject: Re: [boost] [thread] unlock on multiple lockables
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-11-23 04:00:07
Am Monday 23 November 2009 07:30:09 schrieb Gottlob Frege:
> On Sun, Nov 22, 2009 at 9:08 PM, Vicente Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
> > Hi,
> > I don't know if I have already requested that but ...
> > Is there any deep reason to don't provide the equivalent of the free
> > functions lock, try_lock
> My guesses at the reasons:
> > Non-member function lock(Lockable1,Lockable2,...)
> > Non-member function lock(begin,end)
> Locking a bunch of locks is a recipe for deadlock. Do we lock them in
> order? Then hold lock1, lock2, waiting to get lock3? Sounds
look at the documentation, it locks them in an unspecified order that avoids
deadlock - so probably sorted in some arbitrary but stable way, like by the
address of the mutex objects.
> On the other hand, I suppose you could argue that using these
> functions (exclusively) could guarantee that locks were always locked
> in the same order (thus preventing deadlock)?
> > Non-member function try_lock(Lockable1,Lockable2,...)
> > Non-member function try_lock(begin,end)
> Sounds even scarier - after trying lock1, do you try lock2? - so you
> don't get lock1, you do get lock2, other thread gets the opposite ==
it locks all or none.
to the question: I guess you're guessing right. the order in which mutexes are
unlocked doesn't matter, so you can use individual unlock() calls.
that try_lock(begin,end) doesn't work btw.
it uses some non-existent SFNIA (ok, that's society for neuroscience according
to google. you know what I mean) on default arguments, that only
MSVC "supports", to detect if you passed two iterators or two Lockables.
might be fixed now though, I still use 1.38.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk