This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Thread safety clarification

[Get raw message]
On Tue, Nov 13, 2001 at 05:27:37PM -0600, Loren James Rittle wrote:
> > 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?
> ... 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...

The reason for the general prohibition is to allow future optimizations.
Operations that seem to be read-only can (or could) cache information 
or re-organize what's there to improve future queries, and it would 
be unfortunate for them to need to claim locks to do it.

A good example is balanced binary trees, which might be rebalanced
to speed access to a particular range of values that is being accessed
very frequently.  The last dozen values searched might be cached 
separately to avoid the full search.

That makes it unfortunate that the STL containers are documented
as safe for simultaneous read access, because all such optimizations
are now closed unless we are willing to consider breaking code that
depends on the guarantee.  (I would have restricted the guarantee 
only to list and vector, for which optimizations are not likely.)

It happens that the current implementation of basic_string<> would
probably be safe for reading (i.e. const operations) in multiple threads.
That seems unlikely to change, but we'd want to discuss it first here
before guaranteeing it.  
> 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).

The example Loren provides below works fine with no user-level
> #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
> }

Nathan Myers
ncm at cantrip dot org

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]