Thread safety clarification

[Loren James Rittle]

> Are there examples of objects which cannot be accessed from multiple 
> threads simultaneously?

Assuming you are speaking about one instantiated object being known to
multiple threads, this is the default assumption you must make as an
application writer using g++ 3.0 and its implementation of the
standard library.

> For example, can I have multiple threads reading from a
> globally-defined, constant string?

Assuming you mean the C++ string<> not a C-style string, I think the
best answer is don't assume that unless you see it documented as a
special case.  BTW, I am fairly sure that it is not documented as a
such a special case.  The author of string<> prompted the language you
now read in the general FAQ on threading using g++ 3.0 and its
implementation of the standard library...

I think there is a way to ensure that you don't need user-level locks
when working with read-only string<>.  I will sketch it out (and
perhaps Nathan will comment on it).  This example is implied from the
application-level lock requirement rules of our implementation.  The
trick is that memory is shared for a and b (nested object handle, etc)
but the user doesn't know that thus he isn't required to provide any
application-level locks.  If thread_a_code and thread_b_code both use
a, then you need application-level locks around any region accessing a
unless there is a special guarantee for the case (again, I only know
of the ones documented for the STL portion of libstdc++-v3).

Regards,
Loren

#include <string>

const string a = "A really long read-only string...";
const string b = a;

thread_a_code ()
{
  // only use a here
}

thread_b_code ()
{
  // only use b here
}

// No other threads use a or b

main ()
{
  // start thread a
  // start thread b
}