This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/5037: Multithreaded read access to strings not threadsafe on Solaris/Sparc
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: amodra at bigpond dot net dot au
- Cc: ckaes at jabber dot com, gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Thu, 6 Dec 2001 18:33:32 -0600 (CST)
- Subject: Re: libstdc++/5037: Multithreaded read access to strings not threadsafe on Solaris/Sparc
> I believe this file [libstdc++-v3/config/cpu/sparc/*/bits/atomicity.h]
> is broken. __exchange_and_add and __atomic_add use separate locks,
> and so are not protected from each other.
[CC'ing libstdc++ list.]
Yikes! I see exactly what you are saying. I found WWW documentation
on the machine-level locking primitive used on sparc and I completely
concur with your finding. For the record, the i386 atomicity.h file
uses an architecture primitive that requires no such extra memory
word. People have reported failures on sparc that have been
unexplainable and unseen on other platforms (offhand, I don't recall
if they involved multiple processors but I think I understand how this
problem could nail even a single processor). You surely have helped
to solve a major mystery (in my mind at least).
Any best solution (in terms of contention) requires a locking word
related to the first argument. Would a designer of the atomicity.h
abstraction layer prefer to provide such a solution?
I think anyone could provide a correct fix that would suffer
contention... ;-) With my observation above, I think anyone could
provide an efficient solution. I know I could do either in minutes.
IMHO, the trick is going to be fixing this problem without changing
the abstraction layer... We also need to check all other
libstdc++-v3/config/cpu/.../bits/atomicity.h files for this issue.
Regards,
Loren