Re: [boost] [thread] best practice to lock multiple mutexes

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-02-01 14:16:01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 01 February 2008 09:00 am, Walter Horsten wrote:
> > ...
> > try_lock: // label
> > unique_lock< mutex > lk1( mtx1, try_to_lock_t);
> > unique_lock< mutex > lk4( mtx2, try_to_lock_t);
> > unique_lock< mutex > lk7( mtx3, try_to_lock_t);
> > if ( ! ( lk1 && lk2 && lk3) ) goto try_lock;
> > // all mutexes are locked
> > // now modify safely resource 1,2,3
> > ...
> >
> > Maybe you have a better pattern do solve this problem?

I'd just establish a locking order and stick to it.  You can use debug tools 
like helgrind to detect locking order violations, or a mutex wrapper that 
detects locking order violations (shameless plug):

http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/acyclic_mutex.html

Trying to come up with a useable locking order at runtime adds overhead, 
requires all the mutexes to be available for locking in the same context, and 
generates false positives when using aforementioned debugging tools.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHo2/y5vihyNWuA4URAjICAKDZmFEC/nOwz10gsOwkAax4exfzhgCfXNEf
ol9+JpHJ/BDfRNfz39g0AEU=
=vaeK
-----END PGP SIGNATURE-----