Opened 11 years ago
Closed 11 years ago
#5836 closed Bugs (invalid)
tss.cpp: tss_data_dec_use suffers a race condition
Reported by: | Owned by: | viboes | |
---|---|---|---|
Milestone: | To Be Determined | Component: | thread |
Version: | Boost 1.47.0 | Severity: | Problem |
Keywords: | Cc: | noloader@…, viboes |
Description
It appears the reference counting of tss_data_use suffers a race condition. Perhaps it would be best to use an interlocked decrement on tss_data_use:
void tss_data_dec_use(boost::mutex::scoped_lock& lk) { if (0 == --tss_data_use) { tss_data_cleanup_handlers_type::size_type i; for (i = 0; i < tss_data_cleanup_handlers->size(); ++i) { delete (*tss_data_cleanup_handlers)[i]; } delete tss_data_cleanup_handlers; tss_data_cleanup_handlers = 0; lk.unlock(); delete tss_data_mutex; tss_data_mutex = 0; #if defined(BOOST_HAS_WINTHREADS) TlsFree(tss_data_native_key); #elif defined(BOOST_HAS_PTHREADS) pthread_key_delete(tss_data_native_key); #elif defined(BOOST_HAS_MPTASKS) // Don't know what to put here. // But MPTASKS isn't currently maintained anyways... #endif } }
In addition, it appears code built with BOOST_HAS_MPTASKS will fail in unexpected ways. Perhaps it would be a good idea to create a compile time failure to save users:
Index: tss.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/tss.cpp,v retrieving revision 1.20 diff -r1.20 tss.cpp 67a68
#error "MPTASKS isn't currently maintained"
Change History (4)
comment:1 by , 11 years ago
Cc: | added |
---|---|
Component: | None → thread |
Owner: | set to |
comment:2 by , 11 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 11 years ago
Type: | Bugs → Support Requests |
---|
Moved to Support request until resolution clarified.
comment:4 by , 11 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
Type: | Support Requests → Bugs |
IMO, it is protected by the lock given as parameter.
Please, reopen it if you don't agree with the resolution.
Isn't it protected by the lock given as parameter?