Hey all, What happened to the multi-lock semantics? I had expected by now to see something like: // Takes two mutexes as arguments, locking them in a pre-defined order // (ie. lowest ptr first). Blocks until both locked. boost::mutex::dual_scoped_lock // Same as above but recursive. boost::recursive_mutex::dual_scoped_lock // Same as boost::mutex::dual_scoped_lock, however if one cannot be // acquired, both are released (ie. the first is unlocked again). boost::try_mutex::dual_scoped_lock // Same as above but recursive. boost::recursive_try_mutex::dual_scoped_lock // Same as boost::mutex::dual_scoped_lock, however if both can't be // acquired in the specified time limit, both are released. boost::timed_mutex::dual_scoped_lock // Same as above but recursive. boost::recursive_timed_mutex::dual_scoped_lock I assume that a dual_scoped_lock would then have a first() and second() member that would yeild the underlying scoped_lock for the first-locked and second-locked mutex (from which you could compare the mutex it locks to one of your mutexes and figure out which was locked first). Similarly, it would be nice to say, have a 'multi' version of the above for an arbitary number of locks (and an appropriate operator[] rather than first() and second()). We all know the old thing about the way to avoid deadlocks is to acquire them in the same order, and the threads FAQ says some kind of way to do this without the ugly syntax that is in the FAQ being necessary (see http://www.boost.org/doc/html/threads/faq.html#id2786718 and the code segment below which includes implementing such wise advice). I'm sure I could knock something that implements the above (at least for dual) in not too long, implementing something for multi would be harder (though I immagine someone who is familiar with how boost::function works might not have a tough time making an equivalent for mutex locking). Anyway, anyone want to get on to this? -- PreZ :) Death is life's way of telling you you've been fired. -- R. Geis