Boost logo

Threads-Devel :

Subject: Re: [Threads-devel] Verifying boost::condition_variable_any plays nicely with boost::recursive_mutex
From: Anthony Williams (anthony_at_[hidden])
Date: 2009-01-12 16:22:07


At Mon 12 Jan 2009 21:01:16 UTC, Gregory Peele ARA/CFD <gpeele_at_[hidden]> wrote:

> I've recently been tasked with writing a Java-style cross-platform
> asynchronous task execution service in C++ on top of Boost Threads 1.37.
> After implementing this service, my unit tests discovered some
> unexpected behavior (well, unexpected to me anyways) with the way that
> boost::condition_variable_any, boost::recursive_mutex, and
> boost::unique_lock interact. I wanted to find out if this behavior is
> intentional or if it should be considered a bug.
>
> Basically, the problem occurs when the same thread has multiple
> unique_lock objects associated with the same recursive_mutex, and then
> calls condition_variable_any::wait. It appears that the condition
> variable only releases one of the recursive locks, and the mutex is
> still considered locked by the calling thread.

That's as designed. condition_variable_any::wait() calls unlock on the
supplied mutex/lock exactly once. If you use a recursive mutex then
you need to ensure that the calling thread only owns a single lock, or
use a lock wrapper that will save and restore the lock count.

If the wait released all locks held on that mutex this may lead to
bugs with the mutex being implicitly unlocked with broken invariants.

Anthony

-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK

Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk