Subject: [boost] Mutexes claim a Windows event handle
From: Peters, Richard (richard.peters_at_[hidden])
Date: 2010-05-31 06:49:06
I have a problem with boost::recursive_mutex "sometimes" keeping a
handle to a Windows Event. My application uses a lot of objects, each
containing a recursive_mutex. The objects are accessed from different
threads using a scoped_lock (see code below). In Boost 1.34 there was no
problem, but after we switched to 1.39 it seems that the process
collects more and more handles to Windows Events. Only when the objects
that contain the recursive_mutex are destroyed, the handles are released
again. The problem is that I must support 100,000 objects containg
multiple mutexes, so if each mutex can cost one handle the total number
of handles in use may become huge.
I tried the latest Boost version (1.43) but that makes no difference.
The strange thing is that not every object keeps a handle, i.e.: the
number of handles collected is less than the number of objects created.
When increasing the nrActions the number of handles collected comes
closer to the number of objects.
I could understand if a recursive_mutex costs a handle, except that in
boost 1.34 they didn't so I wonder if this was an accident or a
deliberate change. And most important: Is there a way to get the same
behavior as in 1.34 where a mutex did not cost me one handle each?
Thanks for your advice!
class ActiveObject : public boost::enable_shared_from_this<ActiveObject>
std::list< boost::shared_ptr<ActiveObject> > jobList;
for (int nrObjects = 0; nrObjects < 1000; ++nrObjects)
boost::shared_ptr<ActiveObject> pActiveObject( new
for (int nrActions = 0; nrActions < 3; ++nrActions)
// At this point, a lot of handles are in use.
// Here, the handles are released again.
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message.
Thank you for your co-operation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk