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@wanadoo.fr> 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.