Hey all, I ran into a bug in my program relating to a std::set, where the set is accessed by two threads. I used a CRITICAL_SECTION to sync the threads and make sure that only one thread accesses the set at a time. But when I removed an element (the only element) from the set in one thread, then looped through the set in the other thread, I got an access violation even though everything was wrapped in calls to EnterCriticalSection() and LeaveCriticalSection(). I checked the code several times but coudn't see anything wrong; thinking it might be a MSVC bug, I checked this site, and found:
Shouldn't the thread sync'ing from the critical sections have prevented any problems? Or is there something going on under the hood of these tree-based containers that delays a little before exploding (thus bypassing the critical section stuff).. or something? Or should I look altogether elsewhere for the problem?The header <xtree> (original 25 June 1998) presented here eliminates all need for thread locks and corrects a number of thread-safety issues for template classes map, multimap, set, and multiset.
Also, does the term 'thread lock' simply refer to sync stuff like mutexes and critical sections?