Re: [boost] [thread] unlock on multiple lockables

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
> dangerous.

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 ==
> deadlock.

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.