From: Daniel Krügler (dsp_at_[hidden])
Date: 2006-07-11 04:43:22
Hello!,
Its a well-known issue, that Boost-Thread users on Windows machines have
observed that popular leak reporting tools loudly notify a missing
delete for the dynamically allocated mutex in tss_hooks.cpp. A good
overview for this discussion can be found in:
While I don't want to heat up the discussion whether this is actually a
"leak" or not, many code style guides of companies give very bad points
on such behaviour, so I would like to ask whether it is possible to
ensure a proper clean-up of this by code (before the system does), to
keep those detector programs quiet...
Simple question of a non-expert: Couldn't one simply change the current
impl of on_process_exit in tss_hooks.cpp to
extern "C" BOOST_THREAD_DECL void on_process_exit(void)
{
{ // Wrap into scope
boost::call_once(init_threadmon_mutex,
once_init_threadmon_mutex);
boost::mutex::scoped_lock lock(*threadmon_mutex);
BOOST_ASSERT(attached_thread_count == 0);
//Free the tls slot if one was allocated.
if (tls_key != invalid_tls_key) {
TlsFree(tls_key);
tls_key = invalid_tls_key;
}
}
delete threadmon_mutex; // Shouldn't that be the last point of
access??
threadmon_mutex = 0; // For those who prefer a defined value...
}
OK, I see that the docs for this function says: "Must not be omitted;
may be called multiple times."
Question is: Does there exist at least the guarantee, that there is
always the same number of on_process_enter and on_process_exit calls?
If yes: Wouldn't a simply reference counting scheme using one of the
atomic integer incrementing/decrementing functions (also provided by
boost via interlocked.hpp) allow a thread-save deletion of that mutex
object?
Thanks for your patience,
Daniel Krügler