libstdc++/5037: Multithreaded read access to strings not threadsafe on Solaris/Sparc
Loren James Rittle
rittle@latour.rsch.comm.mot.com
Fri Dec 7 09:01:00 GMT 2001
> Yes, a more minimal change for 3.0.x seems advisable.
Agreed. Your patch fits the bill nicely. There is no ABI issue; code
compiled against the old implementation will mix with code compiled
against the new implementation (of course, multithreaded apps will
have to be compiled against only the new implementation to fix the
bug). Do you need me to test it on sparc and install it on mainline?
Since the change affects only one port and has the properties outlined
above, we might still be able to have Mark grant a move to 3.0.x in
time for the 3.0.3 release.
>> ! struct _Atomic_word
>> ! {
>> ! unsigned char __lock;
>> ! int __word;
>> ! operator int() const { return __word; }
>> ! operator = (const int x) { return x == __word; }
>> ! _Atomic_word () : __lock (0), __word (0) {}
>> ! };
> Unfortunately this makes a basic_string<>::_Rep substantially larger.
> Also, it cannot be put in places that need a POD. Probably if we do
> something like this in 3.1 a change to the abstraction layer is
> appropriate.
I think both of your objections to my first effort are completely
accurate. Upon reading the documentation in the porting guide, I see
that it was not even legal to make _Atomic_word a struct of any type
POD or otherwise (it must be a ``signed integral type''. Thus we must
also object to Alan Modra's current work for hppa (perhaps he can make
the internal implementation look like sparc with your patch under the
same reasoning you use about lock contention). No one raised the
issue but since I began to wonder if libstdc++-v3 was itself violating
original intent of the abstraction layer: There is no specification
either way about making calls to __exchange_and_add excluding the
possibility of concurrent calls to __atomic_add and vice versa.
> Do we really expect to see much contention on this lock? It's held
> for such a short time.
Good question. Seeing as I have no data either way (but after
sleeping on it I see your point here as well), KISS says to do it your
way.
Regards,
Loren
More information about the Libstdc++
mailing list