Commit cb580d5c by Loren J. Rittle Committed by Loren J. Rittle

index.html (Is libstdc++-v3 thread-safe?): Update based on Nathan's review.

	* docs/html/faq/index.html (Is libstdc++-v3 thread-safe?): Update
	based on Nathan's review.  Use Nathan's words.

From-SVN: r46238
parent 0c34509f
2001-10-12 Loren J. Rittle <ljrittle@acm.org>
* docs/html/faq/index.html (Is libstdc++-v3 thread-safe?): Update
based on Nathan's review. Use Nathan's words.
2001-10-11 Matt Kraai <kraai@alumni.carnegiemellon.edu> 2001-10-11 Matt Kraai <kraai@alumni.carnegiemellon.edu>
* docs/html/configopts.html: Quote StyleSheet attribute values. * docs/html/configopts.html: Quote StyleSheet attribute values.
......
...@@ -686,7 +686,9 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff ...@@ -686,7 +686,9 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
<hr> <hr>
<h2><a name="5_6">5.6 Is libstdc++-v3 thread-safe?</a></h2> <h2><a name="5_6">5.6 Is libstdc++-v3 thread-safe?</a></h2>
<p>When the system's libc is itself thread-safe, libstdc++-v3 <p>When the system's libc is itself thread-safe, a non-generic
implementation of atomicity.h exists for the architecture, and
gcc itself reports a thread model other than single; libstdc++-v3
strives to be thread-safe. The user-code must guard against strives to be thread-safe. The user-code must guard against
concurrent method calls which may access any particular concurrent method calls which may access any particular
library object's state. Typically, the application library object's state. Typically, the application
...@@ -718,22 +720,12 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff ...@@ -718,22 +720,12 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
object_a.mutate (); object_a.mutate ();
} }
</pre> </pre>
<p>However, as of gcc 3.0 and point releases, beware that there <p>All library objects are safe to use in a multithreaded
may be cases where shared nested or global objects (neither program as long as each thread carefully locks out access by
of which are visible to user-code) are affected or used any other thread while it uses any object visible to another
without any internal locking. thread. This requirement includes both read and write access
<!-- Is this warning still required? - Loren --> to objects; do not assume that two threads may read a shared
</p> standard container at the same time.
<p>In some cases, a stronger thread-safe claim is made. The
string class is thread-safe without user-code guards (i.e. a
string object may be shared and accessed between threads
without user-level locking). The IO classes are thread-safe
with user-code guards whenever the same user-visible object
may be accessed by multiple threads. The container classes
are thread-safe with user-code guards whenever the same
container may be accessed by multiple threads. All accesses
to hidden shared objects (e.g. the global allocator objects)
are believed to be properly guarded within the library.
</p> </p>
<p>See chapters <a href="../17_intro/howto.html#3">17</a>, <p>See chapters <a href="../17_intro/howto.html#3">17</a>,
<a href="../23_containers/howto.html#3">23</a> and <a href="../23_containers/howto.html#3">23</a> and
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment