Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 07:44:48


Matt Hurd <matt.hurd_at_[hidden]> writes:

> On Wed, 14 Jul 2004 15:27:08 -0400, David Abrahams
> <dave_at_[hidden]> wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>> > I have a recursive_mutex use case that's not as trivial, though. Imagine a
>> > mutex pool with a fixed size N that protects an unbounded set of objects
>> > (hashing the object address mod N to determine the mutex to lock). Now when
>> > you need to protect two objects at the same time, due to the probability of
>> > a collision the mutexes need to be recursive. It's still not watertight,
>> > because if the two locks are removed from each other, this seems like a
>> > deadlock invitation; and if the two locks are made at the same time, the
>> > recursive lock can be avoided locally.
>>
>> Can't you just check the hashes and only lock once in that case?
>
> AFAICT, you'd have to record the objects to which the specific thread
> had the lock otherwise you can't discriminate on who owns the lock.

That's only true if a given thread can lock more than two objects at
the same time. Isn't that likely to lead to deadlock, regardless?

If each thread is only limited to locking one pair you can lock the
mutex for the first object, check the 2nd one to see if it's got the
same hash, and if not, lock the 2nd object's mutex.

I'm pretty sure, anyway ;-)

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk