Re: [boost] Multi-lock semantics?

From: Preston A. Elder (prez_at_[hidden])
Date: 2006-01-01 22:27:18

Howard Hinnant wrote:
> Thread 1 locks mutex A and then waits for mutex B to be unlocked.
> Thread 2 is busy with mutex B (but not A).
> Thread 3 blocks on mutex A, even though it doesn't need B, only
> because thread 1 is sitting on it doing nothing.
> 
> If Thread 1 had released A before waiting on B, then both thread 2
> and thread 3 could get work done.
While I agree this is a good way to increase efficiency and such, there is
one problem with it being that it is not FIFO.

Traditionally, mutexes are locked in the order of request, making the order
of locking like a queue, when you request you go to the back of the queue.

The method you describe makes it more of a 'best available' model, which is
nice, however means that thread 1 (in your above example) potentially could
NEVER get its lock.

If thread 2 continually requests lock B and thread 3 continually gets lock
A, and there is some overlap but never a point where both are free, thread
1 will wait forever.

A policy model that supports either fifo or your 'best available' model
would be the best route to go I think, as both models have their own
advantages.

-- 
PreZ :)
Death is life's way of telling you you've been fired.
                -- R. Geis