Ticket #4345 (closed Bugs: fixed)
thread::id and joining problem with cascade of threads
|Reported by:||bartek szurgot <bartosz.szurgot@…>||Owned by:||viboes|
i believe there is a problem when saving thread's ids in an external (for a thread) collection, when joining cascade of threads and collection lives on.
example code, showing this issue has been attached this this report. what happens there:
- main() creates collection of thread::id objects (i.e. Data)
- main() creates two threads (in classes A and B)
- ThreadJoiner? helper class interrupts and joins threads in d-tor, and so main() int+join thread in B class' instance, that in turn int+join A class' instance thread (member of B object)
- check if threads exited, as they should.
each thread increments global counter when entering operator()() and decrements it when leaving operator()()'s scope, so when leaving scope of ThreadJoiner? root object all threads should be already joined. it happens this way (as expected) as long as one does not save thread::ids. if they are saved, and live longer then thread, threads are not (always) joined properly (in attached example program: assertion on global counter equals 0 fails). it looks like race, but is reproducible in ~95% of the cases.
problem does not seem to appear when threads are run directly, and joined from main as well (not cascade).
in example code there are 2 ways to make code work as expected:
- uncomment main.cpp:139 (deallocation of collection of saved IDs before calling joins in d-tors)
- change main.cpp:32 from '#if 1' to '#if 0' - this changes collection to hold std::string (generated via stream, from boost::thread::id) from boost::thread::id
i was able to reproduce this issue with the same results with boost versions:
- today's trunk
toolchain is g++ 4.4.x under Linux (Debian and Ubuntu).
to build and run example code extract bzip2 archive, enter directory and run: make && gen/debug/a.out
comment:10 Changed 5 years ago by viboes
- Cc viboes removed
- Owner changed from anthonyw to viboes
- Status changed from new to assigned
- Milestone changed from Boost 1.43.0 to To Be Determined
comment:18 Changed 5 years ago by viboes
- Status changed from assigned to closed
- Resolution set to fixed