libstdc++/5037: Multithreaded read access to strings not threadsafe on Solaris/Sparc
Nathan Myers
ncm-nospam@cantrip.org
Fri Dec 7 13:57:00 GMT 2001
On Fri, Dec 07, 2001 at 03:03:15PM -0600, Loren James Rittle wrote:
> Here is a version of your patch that builds (libstdc++-v3 cleaned
> before rebuild in already bootstrapped tree), links and passes the
> test case of 5037 on a multiprocessor sparc. Unless you veto it, I
> will install it on mainline and then lobby Mark for it to be moved to
> 3.0.X branch before the 3.0.3 release.
Good. Thank you.
> Obviously, this solution is not portable back to plain C.
> That is a loss ...
I can't see any reason why that would be a loss...
> [With the technique from your patch with my tweak:]
>
> S rittle@magoo; psrinfo -v
> The sparcv9 processor [0, on-line] operates at 248 MHz,
> S rittle@magoo; ./a.out
> 213r 79.9u 33.1s ./a.out
> 142r 25.6u 15.0s ./a.out # built with -O2
>
> S rittle@ss137; psrinfo -v
> The sparc processor [0, on-line] operates at 125 MHz,
> The sparc processor [2, on-line] operates at 125 MHz,
> S rittle@ss137; ./a.out
> 398r 340.7u 139.3s ./a.out
> 259r 171.6u 92.6s ./a.out # built with -O2
>
> S rittle@ss137; psradm -f 2 # take processor 2 off-line
> S rittle@ss137; ./a.out
> 434r 217.0u 109.2s ./a.out
>
> [With my first patch:]
>
> S rittle@magoo; ./a.out
> 213r 77.5u 35.6s ./a.out
>
> S rittle@ss137; ./a.out # processor 2 put back on-line
> 413r 336.1u 152.0s ./a.out
>
> (I didn't bother testing with one slower processor off-line.)
>
> The test case has three threads with one creator thread and two
> consumer threads. Since the creator thread does far more work than
> the two identical consumer threads, I would not expect linear speedup
> with this test case as it is written.
Sorry, I don't understand what these numbers mean. Enlighten?
In particular, is this telling us something about contention?
Nathan Myers
ncm at cantrip dot org
More information about the Libstdc++
mailing list