From: John Maddock (john_at_[hidden])
Date: 2005-09-09 06:34:58
> You can't lock two locks willy-nilly like this. So ideally what I'd
> like to do is create a generic lock function that will lock multiple
> locks without danger of deadlock:
> template <class TryLock1, class TryLock2>
> lock(TryLock1& l1, TryLock2& l2);
> and maybe also:
> template <class TryLock1, class TryLock2, class TryLock3>
> lock(TryLock1& l1, TryLock2& l2, TryLock3& l3);
Yep, those would be useful additions to Boost.Thread IMO.
> Problem: With the current interface, my "generic" lock algorithm is no
> longer generic. It has to know about read_lock() and write_lock(),
> even though these concepts have absolutely nothing to do with how you
> lock two locks while avoiding deadlock.
Ah, that's what happens from looking at my not so good test case, rather
than the docs :-)
try_read_write_mutex does have member typedefs try_read_lock and
try_write_lock, which do what you want them to, I just happened to use a
different locking primitive because it was easier to change the test code
around to test different combinations of readers and writers.
> Sorry, but: Houston, we have an even bigger problem...
Not this time, still it was big enough to begin with :-(
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk