This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
- From: ljrittle at gcc dot gnu dot org
- To: andrew at andypo dot net, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, ljrittle at gcc dot gnu dot org, rodrigc at gcc dot gnu dot org
- Date: 24 Jan 2002 21:26:00 -0000
- Subject: Re: libstdc++/5432: Implementation still not thread-safe on multiprocessor machines
- Reply-to: ljrittle at gcc dot gnu dot org, andrew at andypo dot net, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, ljrittle at gcc dot gnu dot org, rodrigc at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: Implementation still not thread-safe on multiprocessor machines
State-Changed-From-To: analyzed->feedback
State-Changed-By: ljrittle
State-Changed-When: Thu Jan 24 13:25:59 2002
State-Changed-Why:
Andrew, there were two minor issues with your patch:
(And it took collective thought to figure all this out
so don't feel bad. ;-)
In general, static _Atomic_word should always be init'd
to 0 with C++. We think g++ follows the init order
rules of C which are tighter than C++ but for C++
non-zero static values may not be init'd until after main()
has run (the only rule says it must be done "before
the related block [scope] is entered" which might be after
threads were started).
Secondly:
< if (--_M_references == 0) // XXX MT
---
> if (__exchange_and_add(&_M_references, -1) == 1)
is correct (you had == 0). I.e. assuming it was correct
as written (other than thread-safety) your rewrite had a
memory leak.
Other than that, Nathan and I have reviewed the patch;
I have tested it and installed it (that report to
the libstdc++ mailing list). To be closed after you
confirm MP *-*-linux* system fixed as installed and
then I move it to 3.0.X branch. Thanks, Loren
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5432