hierarchical_mutex for lock hierarchies (to avoid deadlocks)

[Fredrik Orderud <forderud@…>]

It would be great if boost::thread could be extended with a "hierarchical" mutex to facilitate lock hierarchies. Lock hierarchies is a construct that associates mutexes with software layer numbers, and enforces the application to only lock "downwards" in the software hierarchy [1]. This effectively translates potential deadlocks into deterministic run-time failures that be detected during testing.

An example draft implementation is attached. The attachment also includes a BOOST_THREAD_LOCAL work-around for missing "thread_local" support that should probably be moved to more neutral ground.

[1] ​http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163

[viboes]

I agree, and I had already on my to do list. However, much more work is needed to move it to Boost:

• make the BOOST_THREAD_LOCAL part portable to compilers that doesn't have the needed feature.
• add timed lock functions
• provide tests
• write the doc: a motivating section, a brief tutorial, an example and the reference

if you can help on any of these task there are more chances the feature is included.

BTW, alternatively you can provide this hierarchical mutex class as a separated library if you prefer.

[anonymous]

Hi Frederick,

what kind of license is you code? Am I allowed to use it as i like? Is it the same as thread's (http://www.boost.org/LICENSE_1_0.txt)

Cheers!

Jan

[Fredrik Orderud <forderud@…>]

Yes, feel free to use my code with the Boost license. :-)

[viboes]

Do you mind to provide some documentation and tests and update your code with the Boost license?

[Fredrik Orderud <forderud@…>]

Revision as of 2014-10-26

[Fredrik Orderud <forderud@…>]

I've now uploaded a 7-zip archive with an updated hierarchical_mutex implementation. All files are tagged with Boost license information. The archive also contains a tiny test suite, as well as a semi-portable "thread_local" emulation.

Feel free to do what ever you want with the implementation. I hope that Boost could consider adopting this pattern in one way or another, since it makes debugging and avoiding deadlocks much easier.