Re: libstdc++/5037: Multithreaded read access to strings not threadsafe on Solaris/Sparc

[Nathan Myers <ncm-nospam at cantrip dot org>]

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