This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: [Bug libstdc++/17664] Crash in std::map when using _GLIBCXX_DEBUG with multithreading


----------  Forwarded Message  ----------
Subject: [Bug libstdc++/17664] Crash in std::map when using _GLIBCXX_DEBUG 
with multithreading
Date: Friday 24 September 2004 16:44
From: "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: lothar@xcerla.com

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-24
 23:44 ------- Invalid as std::map is not multithreaded that way (you would
 have the same problem without _GLIBCXX_DEBUG also as it is not done this way
 for either).  What this is showing you is that you need to add the write
 guard other wise you get a crash or wrong answers without _GLIBCXX_DEBUG.
----------  End Forwarded Message  ----------

I have no intention to reopen the bug unless this topic is clarified.
Thus I moved the discussion to the mailing list.


I have to admit that I do not understand the implication of your comment.

If multiple iterators are independent of each other and the map they iterate 
upon (the data of their position is the only data they change when iterated 
and the data is stored only in the iterator itself) they should very well 
work in multiple threads as long as the map does not change and each thread 
has it's own iterator. This is exactly what the test program tries to do and 
it enforces that with read write locks. If on the other hand there are 
dependencies upon iterators and the map I doubt that it will work correctly 
even for the single threaded case if the program uses multiple distinct 
iterators on the same map. They would influence each other in the single 
threaded case in the same way they influence each other in the multithreaded 
case.

I also wonder why the program crashes only if _GLIBCXX_DEBUG is defined.

I also have to admit that it is very counterintuitive needing to protect a 
read only iteration with a write lock.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]