"Peters, Richard" <richard.peters@oce.com> 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? Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976