Boost logo

Boost :

From: Preston A. Elder (prez_at_[hidden])
Date: 2006-01-01 05:38:25

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.

// Same as above but recursive.

// Same as boost::mutex::dual_scoped_lock, however if one cannot be
// acquired, both are released (ie. the first is unlocked again).

// Same as above but recursive.

// Same as boost::mutex::dual_scoped_lock, however if both can't be
// acquired in the specified time limit, both are released.

// Same as above but recursive.

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at