Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-07-14 18:45:34

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. 
You could do this either as TSS for which object or, alternatively,
via an intrusive which_thread struct (bit field for # of threads?) in
the object I guess.

I don't have a good solution to this.  The way I approach it is just
to write code very carefully to avoid the deadlock, but I still get
bitten from time to time.

On the flip side, if I have a lock per object in a large collection,
on win32 I get tens or hundreds of thousands of kernel objects, this
made me uncomfortable so I went to a vector of mutexes for this puppy
but only as it made me uncomfortable.  Sure this was a bad thing for a
win9X, but I have not been able to dig up, or see, any problems with
doing this on win32 (i.e. it works) apart from the fact that it looks
strange and no-one else seems to do it, which is enough to make me
nervous.  Any advice here?

$AUD 0.02,

Matt Hurd.