This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: libstdc++/7926
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Tue, 5 Nov 2002 00:47:56 -0600 (CST)
- Subject: Re: libstdc++/7926
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
- References: <20021104235307.A25914@disaster.jaj.com>
In article <200211050500.gA550nlo038470@latour.rsch.comm.mot.com> you write:
>> I was/am expecting that generic/atomicity.h would be fixed to use gthr.h's
>> mutexes before 3.2.1 is shipped...
> As long as the patch to fix i386 isn't moved to release branch before
> generic/atomicity.h is updated to make correct rather than fast,
> I guess my complaints are withdrawn. It would still be nice to
> figure out correct code for plain i386 that also worked on later iX86
> and SMP configurations, but that is outside my area (I posted one
> example to start discussion).
Oops, of course, I wrote too soon. This configuration change would
result in an internal implementation change that *will* compromise
thread-safety if matched with code compiled the other way. IMHO, it
should be saved for 3.3 unless we clearly publish what ports are no
longer thread-safe due to the bug fix for pure i386 ports.
Since there was no thread safety with generic/atomicity.h anyways,
adding the gthr.h mutex should be safe to move to 3.2.X whenever (and
is a real bug fix for users that have always used generic). People
that link old code against new get nothing worse than before. People
that recompile everything, get the fix.
Of course, if the blasted thing wasn't (possibly) inlined into every
compilation, then we could consider moving the fix more aggressively.
This has been broken since gcc 3.0 shipped and this is the first PR.
Given the numbers involved, it is better to document that pure i386
machines are basically hosed when it comes to threading support in
libstdc++-v3 until gcc 3.3 is released.
Regards,
Loren