-----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/acy... 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-----