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

[Loren James Rittle]

>> 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.

OK, will be committed to mainline ASAP.

>> 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...

Well, we can't give the fix back to glibc in this case... ;-)

>> [...] 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?

Sorry, I should have included my analysis instead of keeping it in my
head.  First of all, one thing that threw me for a while: wall (real)
time doesn't more or less match user+system time (at least for single
processor runs) since there is a sleep(1) call in the creator thread's
main loop (however, it only triggers once ever 10000 times of loop
that runs 1000000 times).  Had I noticed the sleep() call before
gathering the data, I would have first verified that the test still
readily failed with an alternate design that removed it yet still
ensured the consumer threads processed most/all of the cycles.

The only thing I am willing to state from the numbers is that your
one-lock solution is no worse for this test case than my proposed
effective ABI-changing lock-per-atomic-word solution (which I though
was important in any real solution ;-).  Since the low-level spinlock
code is running in user space, the u number is the only one we should
have to consider to study contention on the spin-lock.

Your patch technique, 1 processor: 217.0u
Your patch technique, 2 processors: 340.7u
My first patch, 2 processors: 336.1u

The number for your technique is within 1% of my technique on 2
processors.  However, we may not say anything about contention by only
comparing ``Your patch technique, 1 processor'' with ``Your patch
technique, 2 processors'' since there may be many extra communications
requiring u time (I just don't know hos Solaris' implementation
behaves) between processors once we go beyond 1.  Off-hand I don't
even know how many independent atomic words are in use at any one
time.  Since one new user-level string<> is created per loop run, I am
guessing that some multiple of 1000000 are in use over the course of
the entire test run.  Thus, I would say a non-trivial number of such
atomic word could exist at any one time.

BTW, I finally see the beauty of the design you used with string<>.  I
admit that I still don't fully see how to efficiently map the concept
to a situation where we want to protect a region of code (as I think
we will still need to do for shared memory management) instead of
maintaining a code word or count as you do for string<>.

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672