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

[Nathan Myers]

On Fri, Dec 07, 2001 at 06:39:58PM -0600, Loren James Rittle wrote:
> 
> The number for your technique is within 1% of my technique on 2
> processors.

I.e., we don't know what it would be like with 32 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.

Without looking at the source, I would guess any contention is probably 
all over the reference count on the empty string's _Rep.  That would
probably be the case in real programs, too.  I.e., if there's much
contention, it is concentrated on a few items and correspondingly few
lock bytes.

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

The general idea is that you can do time-consuming operations like 
bulk allocation under a mutex, and then, using an atomic-swap operation,
link the results into a global data structure that makes it available 
to all threads.  Other threads can consume sub-blocks using the same 
atomic-swap operation without engaging the mutex.  The only tricky bit 
(aside from implementing atomic-swap on all the architectures) is that, 
once you obtain the mutex, you have to verify that you still need to do 
whatever you were locking it for, because whoever had the lock might
have done it already.

A condition variable is better for this sort of thing, if we have a
portable interface for that.

Nathan Myers
ncm at cantrip dot org