OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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
This commit is contained in:
Loren J. Rittle 2001-10-13 00:06:21 +00:00 committed by Loren J. Rittle
parent 0c34509f6d
commit cb580d5cac
2 changed files with 14 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
libstdc++-v3/ChangeLog
View File

@ -1,3 +1,8 @@
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.

26
libstdc++-v3/docs/html/faq/index.html
View File

@ -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
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