Boost logo

Boost :

Subject: Re: [boost] Mutexes claim a Windows event handle
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2010-06-01 02:42:27

"Peters, Richard" <richard.peters_at_[hidden]> writes:

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

The old boost::mutex implementation used CRITICAL_SECTION on Windows;
the new version uses atomics and a lazy-allocated Event, which is only
allocated in the case of actual contention on the
mutex. CRITICAL_SECTION objects have similar behaviour.
> 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.

That's the lazy allocation at work --- you only need the Event if
there's contention for the mutex.

> 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?

No, there is not.

Why do you need so many mutexes?


Author of C++ Concurrency in Action
just::thread C++0x thread library   
Just Software Solutions Ltd
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Boost list run by bdawes at, gregod at, cpdaniel at, john at