map iterators with multithreading and _GLIBCXX_DEBUG

[Lothar Werzinger]

Hi,

I searched the bugzilla and the mailing list, but I found nothing matching.

We had crashes in some multithreaded tests, so I digged into them and this are 
my findings:

This is what we do:
1.) The test compiles with the _GLIBCXX_DEBUG preprocessor macro set.
2.) The test uses a map<int,int> which is shared across multiple threads.
3.) Each access to the map is protected with a read or write mutex.
4.) The test uses an (const_)iterator obtained by map.find()

It seems that if the STL is compiled/used with _GLIBCXX_DEBUG moving iterators 
is not thread safe. In our case we had multiple threads (each of them held a 
read lock) and every thread had its own iterator (obtained by map.find()) and 
iterated until the end of the container (No it does not dereference 
map.end() ;-)). Note that it is legal to have multiple threads in a read 
lock, but only a single thread in a write lock. The test guards all 
modifications to the map (like inserts) with a write guard and all read 
access (like find) with read guards.

The test crashes only if compiled with _GLIBCXX_DEBUG; without it runs fine.
I think this is a bug in libstdc++, as iterators that are not shared across 
threads should work independently. The problem goes away as soon as the test 
guards the ++iter expression with a write lock.

I assume that the debug STL (_GLIBCXX_DEBUG) does modify something (on the 
map) it does not without _GLIBCXX_DEBUG, as the test runs fine when compiled 
without _GLIBCXX_DEBUG.

I think STL should (ideally) behave identically wether _GLIBCXX_DEBUG is used 
or not. Therefore if the _GLIBCXX_DEBUG version needs to alter some state it 
should be protected internally to provide the same behavior to the caller.

If you have any questions, please follow up.

Thanks!
Lothar
-- 
Lothar Werzinger Dipl.-Ing. Univ.
framework & platform architect
Xcerla Corporation
275 Tennant Avenue, Suite 202
Morgan Hill, Ca 95037
email: lothar@xcerla.com
phone: +1-408-776-9018