Re: thread-safe strings

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

On Wed, Mar 15, 2000 at 08:50:07AM -0500, brent@linux1.org wrote:
> on Wed, Mar 15, 2000 at 04:07:27AM -0800, Nathan Myers typed aloud:
>    > > I've looked over the code for basic_string a bit and see that there
>    > > is a problem with _M_state being accessed from multiple threads.
>     
>    There is no need for a mutex, thus no need for a thread library.
> 
> Thanks for the lesson. Would _M_state need to be similarly
> locked when being modified in other places? I see quite a few
> places where it is being tested then set to a new value, --
> (line 249, bits/string.tcc)
> 
>       if (_M_rep()->_M_state > 0) 
>         _M_mutate(0, 0, 0);
>       _M_rep()->_M_state = -1;
> 
> -- or is this safe? 

I looked at all uses of _M_state.  Generally, if there can be only
one thread (legally) looking at it, no synchronization is needed.  
After a test 

  if (_M_state <= 0) ...

we know that the storage is not shared with any other string instances.

Note that we are explicitly _not_ trying to make code like the 
following safe:

  // thread 1   // thread 2
  s += 'a';     s += 'b';

That will lose regardless of what we do.  The thread-safety we are
supporting allows this:

  // thread 1   // thread 2
  s += 'a';     t += 'b';

where s and t (initially) share a common representation.
(To have got that way, safely, probably required an explicit lock
in user code.)

---
Note Note Note Note Note Note Note Note Note Note Note Note Note Note Note

Having read stl/bits/pthread_allocimpl.h, I am concerned that the
usage pattern in string is precisely what the comments at the top
of the file warn about.  Fixing it might require annotating string
storage with a hint about which pool it came from, or worse.

Nathan Myers
ncm@nospam.cantrip.org