Thread safe strings? - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Thread safe strings?
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

Samuel Jackson
Guest

Posted: Thu Sep 18, 2003 9:56 am Post subject: Thread safe strings?

Howdy, I'm writing a multi-threaded C++ program on HP-UX using gcc 3.2.3 and am having issues with std::strings. I've been looking over the previous posts and elsewhere on the web and it seems as if the STL string class is not thread safe. I use mutexes around any shared data, but it looks as if the static class members of std::string are getting munged and throwing exceptions. What can one do about strings not being thread safe in this regard? I can't go around putting locks around each string operation (I don't think.) Are there alternatives to the STL strings that one can use that maybe a little less optimized but thread safe? thanks for any help If there is a FM that I should get in order to RTFM that'd be great Sam [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Ben Hutchings
Guest

Posted: Fri Sep 19, 2003 10:00 am Post subject: Re: Thread safe strings?

In article <223bb155.0309171625.7d7ebfb2 (AT) posting (DOT) google.com>,
Samuel Jackson wrote:

Quote:

I'm writing a multi-threaded C++ program on HP-UX using gcc 3.2.3 and
am having issues with std::strings. I've been looking over the
previous posts and elsewhere on the web and it *seems* as if the STL
string class is not thread safe. I use mutexes around any shared
data, but it looks as if the static class members of std::string are
getting munged and throwing exceptions.

The standard unfortunately doesn't say anything about threads and
thread-safety; thread support is, for now, an implementation issue.

Some (most?) implementations make the guarantee that it is safe for
multiple threads to read from the same container simultaneously and
that it is safe for a thread to modify a container while other
threads are reading or modifying other containers. Any further
thread-safety requires synchronisation by the user.

The standard encourages implementors to make string copying cheap
by using a handle-body pattern and copying the body of the string
only when it is (or may be) about to be changed in one string
instance (this is called copy-on-write). Obviously this sharing
makes it impossible to provide the above guarantee without making
many string operations use synchronisation. I am not aware of any
implementation that does use synchronisation for this; so any that
does use "copy-on-write" does not provide that guarantee.

The standard C++ library for GCC 3.x is libstdc++-v3 which does
provide the guarantee and does not have copy-on-write strings.
STLport is similar. So I wonder which library you are using?

There is always the possibility that you accidentally built a
non-thread-aware version of libstdc++.

Quote:

What can one do about strings not being thread safe in this regard? I
can't go around putting locks around each string operation (I don't
think.) Are there alternatives to the STL strings that one can use
that maybe a little less optimized but thread safe?

Make sure you're using the right library, first.

Quote:

thanks for any help

If there is a FM that I should get in order to RTFM that'd be great

I don't think there is.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Joshua Lehrer
Guest

Posted: Fri Sep 19, 2003 10:08 am Post subject: Re: Thread safe strings?

[email]sami_jackson (AT) hotmail (DOT) com[/email] (Samuel Jackson) wrote in message news:<223bb155.0309171625.7d7ebfb2 (AT) posting (DOT) google.com>...

Quote:

Howdy,

I'm writing a multi-threaded C++ program on HP-UX using gcc 3.2.3 and
am having issues with std::strings. I've been looking over the
previous posts and elsewhere on the web and it *seems* as if the STL
string class is not thread safe. I use mutexes around any shared
data, but it looks as if the static class members of std::string are
getting munged and throwing exceptions.

What can one do about strings not being thread safe in this regard? I
can't go around putting locks around each string operation (I don't
think.) Are there alternatives to the STL strings that one can use
that maybe a little less optimized but thread safe?

thanks for any help

std::string is equally as thread safe as any other standard object.
Two threads may observe the value at the same time. However, if any
thread is modifying the value, then it must have exclusive access.

If you have a global const std::string, there is no need for any
locking (assuming no nasty const_casts<>). If you have a global
std::string, that multiple threads may be modifying and reading, then
it must be locked upon access.

Likewise, if you have a global T, for which multiple threads may read
and write, it must be locked during access. It doesn't matter if T is
an std::string or an std::map.

joshua lehrer
factset research systems
NYSE:FDS

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jakob Bieling
Guest

Posted: Fri Sep 19, 2003 10:09 am Post subject: Re: Thread safe strings?

"Samuel Jackson" <sami_jackson (AT) hotmail (DOT) com> wrote

Quote:

Your implementation might provide a thread-safe std::string class. The
point is, that the Standard does not say anything about threads at all, so
it also does not say whether the std::string class must be thread-safe or
not.

Quote:

What can one do about strings not being thread safe in this regard? I

Either write your own wrapper class around the std::string class, in
which you provide the synchronisation, or write a whole new string class, or
just synchronise access to the std::string classes by hand.

Quote:

can't go around putting locks around each string operation (I don't
think.) Are there alternatives to the STL strings that one can use
that maybe a little less optimized but thread safe?

Not too sure, but either Google will find you some, or if that is not
good enough of a search, go to open-source websites ..
http://www.planetsourcecode.com is one of them.

hth
--
jb

(replace y with x if you want to reply by e-mail)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Andrei Alexandrescu
Guest

Posted: Fri Sep 19, 2003 10:30 am Post subject: Re: Thread safe strings?

"Samuel Jackson" <sami_jackson (AT) hotmail (DOT) com> wrote

Quote:

Are there alternatives to the STL strings that one can use
that maybe a little less optimized but thread safe?

You may want to check
http://www.moderncppdesign.com/publications/cuj-06-2001.html, which
describes an implementation of the basic_string interface that you can
customize in various ways.

Andrei

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Mon Sep 22, 2003 3:08 pm Post subject: Re: Thread safe strings?

Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes:

Quote:

In article <223bb155.0309171625.7d7ebfb2 (AT) posting (DOT) google.com>,
Samuel Jackson wrote:
I'm writing a multi-threaded C++ program on HP-UX using gcc 3.2.3
and am having issues with std::strings. I've been looking over the
previous posts and elsewhere on the web and it *seems* as if the
STL string class is not thread safe. I use mutexes around any
shared data, but it looks as if the static class members of
std::string are getting munged and throwing exceptions.

The standard unfortunately doesn't say anything about threads and
thread-safety; thread support is, for now, an implementation issue.

Still, if the implementation supports threads in general, it should
specify the guarantees it makes for its library functions. (If the
implementation doesn't support threads in general, you cannot use it for
a multithreaded function.)

Quote:

Some (most?) implementations make the guarantee that it is safe for
multiple threads to read from the same container simultaneously and
that it is safe for a thread to modify a container while other
threads are reading or modifying other containers. Any further
thread-safety requires synchronisation by the user.

This is the usual guarantee. Some libraries, such as Rogue Wave, make
futher guarantees.

Quote:

The standard encourages implementors to make string copying cheap by
using a handle-body pattern and copying the body of the string only
when it is (or may be) about to be changed in one string instance
(this is called copy-on-write).

The standard explicitly allows such an implementation, but does a
maximum to ensure that it can't be done efficiently. In a multithreaded
environment, I've only seen one implementation, Rogue Wave, which comes
close to getting it right, and they do so by taking a mutex lock at
every operation -- which is incredibly expensive in run-time.

Quote:

Obviously this sharing makes it impossible to provide the above
guarantee without making many string operations use synchronisation.
I am not aware of any implementation that does use synchronisation

Rogue Wave.

Quote:

for this; so any that does use "copy-on-write" does not provide that
guarantee.

As far as I know, Rogue Wave and g++ are the only implementations still
using copy-on-write. The Rogue Wave implementation acquires a lock on
every operation, at exceptional run-time cost, and the g++
implementation isn't thread safe.

Quote:

The standard C++ library for GCC 3.x is libstdc++-v3 which does
provide the guarantee and does not have copy-on-write strings.

At least as late as g++ 3.2.2, the standard basic_string was
copy-on-write. And not thread safe.

--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ben Hutchings
Guest

Posted: Tue Oct 14, 2003 9:20 pm Post subject: Re: Thread safe strings?

In article <86n0cy9g5w.fsf (AT) alex (DOT) gabi-soft.fr>, James Kanze wrote:

Quote:

Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes:
snip
|> The standard C++ library for GCC 3.x is libstdc++-v3 which does
|> provide the guarantee and does not have copy-on-write strings.

At least as late as g++ 3.2.2, the standard basic_string was
copy-on-write.

You're right; I don't know why I thought that had changed.

Quote:

And not thread safe.

The implementation calls atomic update functions to modify the
reference count of a shared body, so I think it is thread-safe
when correctly configured.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Randy Maddox
Guest

Posted: Thu Oct 16, 2003 8:52 pm Post subject: Re: Thread safe strings?

Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> wrote

Quote:

In article <86n0cy9g5w.fsf (AT) alex (DOT) gabi-soft.fr>, James Kanze wrote:
Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes:
snip
|> The standard C++ library for GCC 3.x is libstdc++-v3 which does
|> provide the guarantee and does not have copy-on-write strings.

At least as late as g++ 3.2.2, the standard basic_string was
copy-on-write.

You're right; I don't know why I thought that had changed.

And not thread safe.

The implementation calls atomic update functions to modify the
reference count of a shared body, so I think it is thread-safe
when correctly configured.

There is no such thing as a thread safe string, nor is such a creature
possible by any stretch of the imagination. The reason is that any
locking provided by the string itself cannot always match the
granularity of locking required by the application.

For example, suppose we have a "thread safe" string class that
guarantees that each and every individual operation on the string will
be performed safely in the presence of multiple threads. Sounds good,
but ...

Say we have one thread that is iterating through the string replacing
some character with another character. The operation itself doesn't
matter, only that one thread is iterating through the string and
modifying it.

Now, another thread reads the same string. What does the second
thread see? Bingo. What the second thread sees is dependent on how
far the first thread has gotten.

The problem is that making individual operations thread safe, which is
really all a class can do on its own, does not provide thread safety
across compound operations that consist of multiple individual class
operations. For this type of operation the application, and only the
application, has the context to know the boundaries of the compound
operation. Thus it is incumbent upon that application to lock the
object prior to the start of the compound operation, and unlock it
when the compound operation is complete.

And there is the other problem. Once the application synchronizes
access to the object such that the compound operation is thread safe,
then the lower level locking provided by the class itself on its
individual operations is redundant, useless, and wasteful.

Randy.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze@gabi-soft.fr
Guest

Posted: Thu Oct 16, 2003 8:55 pm Post subject: Re: Thread safe strings?

Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> wrote

Quote:

There is a race condition in the non-const version of operator[]. I
forget the exact details, but basically, it doesn't work if one thread
is copying and/or deleting copies of a non-const instance while another
thread is using operator[] on the same instance -- if I remember right,
the image gets marked as isolated (leaked is the word used in the code)
when in fact it is shared between two instances.

The problem is that the test that the image isn't shared isn't atomic
with regards to marking it as isolated/leaked. And the real problem is
that operator[] can't know that the client code will not modify. The
situation couldn't normally occur, because if any one thread is
modifying, all threads need a lock. Except that here, no client code is
modifying, but the implementation of std::string has to suppose that it
is, and takes steps accordingly.

Other than that, of course, the last time I looked, the implemenation of
the atomic functions for Sparc Solaris could deadlock.

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Hovik Melikyan
Guest

Posted: Fri Oct 17, 2003 11:47 am Post subject: Re: Thread safe strings?

"Randy Maddox" <rmaddox (AT) isicns (DOT) com> wrote

Quote:

The problem is that making individual operations thread safe, which is
really all a class can do on its own, does not provide thread safety
across compound operations that consist of multiple individual class
operations. For this type of operation the application, and only the
application, has the context to know the boundaries of the compound
operation. Thus it is incumbent upon that application to lock the
object prior to the start of the compound operation, and unlock it
when the compound operation is complete.

One possible solution to have an absolutely and unconditionally safe string
class is, I think, to create a wrapper around a 'basically' safe string
(i.e. one that does safe copy-on-write but does not guarantee safety for
other operations). This wrapper can have a limited functionality to ensure
that each interface method it provides is safe in all respects. It would
definitely lack at least operator[], though maybe some other methods too.
(Similar to atomic int's that have, again, very limited functionality.) In
addition this class should have methods that typecast to or assign from a
basic string.

Consider you have global strings, exactly like global int's, shared between
threads. Any thread can obtain a basic string 'incapsulated' in a safe
string and go ahead use and/or modify it in any way _locally_. OTOH, any
thread can form a string and then, as a final step, assign it to a global
safe string, thus making it available for other threads.

One more important thing: I think such string class can make use of
lock-free CAS-based algorithms.

Quote:

And there is the other problem. Once the application synchronizes
access to the object such that the compound operation is thread safe,
then the lower level locking provided by the class itself on its
individual operations is redundant, useless, and wasteful.

A safe wrapper object allows you to obtain a string that's faster (and less
safe, obviously).

Generally speaking, many fundamental data types can be wrapped with a safe
(and possibly limited) interface that guarantees atomicity and provides
means of obtaining the incapsulated unsafe object for local use.

Would this make sense?

--
Hovik Melikyan

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ben Hutchings
Guest

Posted: Sat Oct 18, 2003 8:31 am Post subject: Re: Thread safe strings?

[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:

Quote:

Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> wrote in message
news:<slrnbooevi.98.do-not-spam-benh (AT) tin (DOT) bwsint.com>...
In article <86n0cy9g5w.fsf (AT) alex (DOT) gabi-soft.fr>, James Kanze wrote:
Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes:
snip
|> The standard C++ library for GCC 3.x is libstdc++-v3 which does
|> provide the guarantee and does not have copy-on-write strings.

At least as late as g++ 3.2.2, the standard basic_string was
copy-on-write.

You're right; I don't know why I thought that had changed.

And not thread safe.

The implementation calls atomic update functions to modify the
reference count of a shared body, so I think it is thread-safe when
correctly configured.

There is a race condition in the non-const version of operator[]. I
forget the exact details, but basically, it doesn't work if one thread
is copying and/or deleting copies of a non-const instance while another
thread is using operator[] on the same instance -- if I remember right,
the image gets marked as isolated (leaked is the word used in the code)
when in fact it is shared between two instances.

I found your report at
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350>.

This is seriously unpleasant! I had not thought of the case where an
instance of string (rather than just a string body) is shared between
two threads, but given the general promise that sequences can be
shared read-only without locking it seems reasonable. However the bug
does not seem to be getting the attention it should have.

Quote:

The problem is that the test that the image isn't shared isn't atomic
with regards to marking it as isolated/leaked. And the real problem is
that operator[] can't know that the client code will not modify. The
situation couldn't normally occur, because if any one thread is
modifying, all threads need a lock. Except that here, no client code is
modifying, but the implementation of std::string has to suppose that it
is, and takes steps accordingly.

Other than that, of course, the last time I looked, the implemenation of
the atomic functions for Sparc Solaris could deadlock.

That seems to have been fixed a while ago:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5037>

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Alexander Terekhov
Guest

Posted: Sat Oct 18, 2003 11:11 pm Post subject: Re: Thread safe strings?

Ben Hutchings wrote:
[...]

Quote:

I found your report at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350>.

This is seriously unpleasant! I had not thought of the case where an
instance of string (rather than just a string body) is shared between
two threads, but given the general promise that sequences can be
shared read-only without locking it seems reasonable.

"read-only" sharing is fine. Why not simply provide a "string const &
reas_access()" wrapper? Well, I sort of know why "not"... ;-)

http://groups.google.com/groups?selm=3F82893E.D05AB97D%40web.de

Quote:

However the bug
does not seem to be getting the attention it should have.

The bug is in the application, not in the implementation, AFAICS.

regards,
alexander.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Sun Oct 19, 2003 9:43 pm Post subject: Re: Thread safe strings?

Alexander Terekhov <terekhov (AT) web (DOT) de> writes:

Quote:

http://groups.google.com/groups?selm=3F82893E.D05AB97D%40web.de

However the bug
does not seem to be getting the attention it should have.

The bug is in the application, not in the implementation, AFAICS.

Not if std::string is to be considered like one of the basic types. If
I replace std::string with char[], and the copy construction with
strcpy, the code is perfectly valid according to Posix.

--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Sun Oct 19, 2003 9:43 pm Post subject: Re: Thread safe strings?

Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes:

Quote:

kanze (AT) gabi-soft (DOT) fr wrote:
Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> wrote in message
news:<slrnbooevi.98.do-not-spam-benh (AT) tin (DOT) bwsint.com>...
In article <86n0cy9g5w.fsf (AT) alex (DOT) gabi-soft.fr>, James Kanze wrote:
Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes:
snip
|> The standard C++ library for GCC 3.x is libstdc++-v3 which
|> does provide the guarantee and does not have copy-on-write
|> strings.

At least as late as g++ 3.2.2, the standard basic_string was
copy-on-write.

You're right; I don't know why I thought that had changed.

And not thread safe.

The implementation calls atomic update functions to modify the
reference count of a shared body, so I think it is thread-safe
when correctly configured.

There is a race condition in the non-const version of operator[].
I forget the exact details, but basically, it doesn't work if one
thread is copying and/or deleting copies of a non-const instance
while another thread is using operator[] on the same instance --
if I remember right, the image gets marked as isolated (leaked is
the word used in the code) when in fact it is shared between two
instances.

I found your report at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350>.

This is seriously unpleasant! I had not thought of the case where
an instance of string (rather than just a string body) is shared
between two threads, but given the general promise that sequences
can be shared read-only without locking it seems reasonable.

It's the Posix convention. It's what Posix promesses for basic types.
In the absence of any real documentation otherwise, it is what I assume
under the vocable "thread safe".

Quote:

However the bug does not seem to be getting the attention it should
have.

Well, to be fair, it is very, very difficult to produce. Note that the
problem can only occur on the first use of operator[] -- after than, the
implementation buffer has been isolated (or "leaked" -- what a
misleading name). And the circumstances in which you could get a single
string object visible in several threads, while never having a write
access in any of the threads, aren't that frequent in real code either.

On the other hand, I sometimes wonder about the seriousness of g++ with
regards to threading. Not because of this error -- it's something that
even the most serious programmer could miss. But because I cannot find
any documentation with regards to what they mean by thread safety, or
what they want to support. IMHO, writing such documentation is the very
first thing you have to do if you want to support threads.

Quote:

The problem is that the test that the image isn't shared isn't
atomic with regards to marking it as isolated/leaked. And the
real problem is that operator[] can't know that the client code
will not modify. The situation couldn't normally occur, because
if any one thread is modifying, all threads need a lock. Except
that here, no client code is modifying, but the implementation of
std::string has to suppose that it is, and takes steps
accordingly.

Other than that, of course, the last time I looked, the
implemenation of the atomic functions for Sparc Solaris could
deadlock.

That seems to have been fixed a while ago:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5037

That's good news. (I'll admit that I hadn't checked lately.) I know
how to avoid the other one, but 32 bit Sparc's are my major platform at
present. (It would be nice if I could tell g++ to use the v9
instruction set, even though I am in 32 bit mode, since I am pretty sure
that all of my actual targets are v9 or above.)

--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ben Hutchings
Guest

Posted: Tue Oct 21, 2003 3:29 pm Post subject: Re: Thread safe strings?

James Kanze wrote:

Quote:

Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes:

|> [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
[re GNU implementation of std::basic_string]

<snip>

Quote:

|> > There is a race condition in the non-const version of operator[].
|> > I forget the exact details, but basically, it doesn't work if one
|> > thread is copying and/or deleting copies of a non-const instance
|> > while another thread is using operator[] on the same instance --
|> > if I remember right, the image gets marked as isolated (leaked is
|> > the word used in the code) when in fact it is shared between two
|> > instances.

|> I found your report at
|> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350>.
snip
|> However the bug does not seem to be getting the attention it should
|> have.

Well, to be fair, it is very, very difficult to produce. Note that the
problem can only occur on the first use of operator[] -- after than, the
implementation buffer has been isolated (or "leaked" -- what a
misleading name).

I think that the name refers to the "leaking" of the buffer address
into the client (in an iterator, pointer or reference) which is what
makes it unsafe to continue sharing the buffer.

<snip>

Quote:

On the other hand, I sometimes wonder about the seriousness of g++ with
regards to threading. Not because of this error -- it's something that
even the most serious programmer could miss. But because I cannot find
any documentation with regards to what they mean by thread safety, or
what they want to support. IMHO, writing such documentation is the very
first thing you have to do if you want to support threads.
snip

<http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#3>

"A minor problem that pops up every so often is different
interpretations of what "thread-safe" means for a library (not a
general program). We currently use the same definition that SGI
uses for their STL subset. However, the exception for read-only
containers only applies to the STL components."

"STL components" ought to be clearly defined but I believe it means
the containers that are included in the SGI STL, which include
basic_string.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum