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?
Typically implementations lazily create the Event object when the mutex cannot be aquired. I guess that Boost Thread's implementation is doing this in the same fashion as Window's CRITICAL_SECTION. I don't have Boost 1.34 around, but I would be surprised if there never was an Event object related to the mutex.. Have nothing else changed in your application, that increases the chance of thread contention? / Christian