That's a hairy one :) I dealt with something like this at some point. Doesn't sound too bad, this approach. One thing you should not forget is, when finding out that you didn't lock all resources you wanted, unlock the ones you did get the lock for and sleep a while before retrying. Otherwise you will end up in a deadlock, at some point or the lock attempt will eat your CPUcycles. Some OS/thread schedulers don't do well with a tight loop ie: the other thread(s) will get hardly any CPU time at all anymore. Propably, but that may be dependent on the access frequency and/or pattern to the resources and the proportion of number of threads to number of resources and the amount of time spent by the thread modifying or working with the resources, you may be better of by having just a single mutex ... If you need to spend more time waiting to lock only the objects you need than it actually takes to work on/with the resources, than that is not a win-win situation. HTH, Harro Verkouter Kowalke Oliver (QD IT PA AS) wrote:
Hi, what's the best practice in following scenario: m threads and n resources (each resource is protected by a mutex) thread x needs read/write access to resources (...i,j,k,..) threads y,z,... do access another subset of resources at the same time
inorder to protected deadlocks I would do following in the code of the different threads (code executed by the threads are different):
... 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?
best regards, Oliver
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost