$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Glen Knowles (gknowles_at_[hidden])
Date: 2004-07-09 22:00:12
> From: Howard Hinnant [mailto:hinnant_at_[hidden]]
> On Jul 9, 2004, at 7:10 PM, Glen Knowles wrote:
> >> Without try locks, lock_both can't be made to work without risking
> >> deadlock.
> >
> > Lock_both can be made to work with try locks? Either you
> have a way to
> > deterministicly set the order you lock the mutexes or you have
> > problems. You can avoid deadlocking with try lock, but you
> will fail
> > to get the pair of locks in cases were you would have gotten it by
> > waiting. I suppose you could just keep try-locking both
> ways until you
> > get it, but that's not good for performance. :)
>
> Well actually keep try-locking both ways is what I've been
> doing. I'd agree with you that in a heavily contested
> context, performance could theoretically suffer arbitrarily badly.
>
> > One solution to this problem would be mutex::operator<
>
> <nod> I just implemented lock_both::lock two ways: Once
> just keep try-locking both ways, and once locking in the
> order of the addresses of the locks (with only two locks in
> the test, this was a safe operator<). My test looks like:
The problem case for spinning is when one thread gets the locks and the
holds them for a non-trivial length of time. During that time the other,
spinning thread, just wastes cpu as fast as it can. This just gets magnified
as more threads are involved.
Glen