This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Fwd: [Bug libstdc++/17664] Crash in std::map when using _GLIBCXX_DEBUG with multithreading
- From: Lothar Werzinger <lothar at xcerla dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: Andrew Pinski <pinskia at gcc dot gnu dot org>
- Date: Fri, 24 Sep 2004 17:23:56 -0700
- Subject: Fwd: [Bug libstdc++/17664] Crash in std::map when using _GLIBCXX_DEBUG with multithreading
- Organization: Xcerla Corporation
---------- 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