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>
* 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>
<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
concurrent method calls which may access any particular
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 ();
}
</pre>
<p>However, as of gcc 3.0 and point releases, beware that there
may be cases where shared nested or global objects (neither
of which are visible to user-code) are affected or used
without any internal locking.
<!-- Is this warning still required? - Loren -->
</p>
<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>All library objects are safe to use in a multithreaded
program as long as each thread carefully locks out access by
any other thread while it uses any object visible to another
thread. This requirement includes both read and write access
to objects; do not assume that two threads may read a shared
standard container at the same time.
</p>
<p>See chapters <a href="../17_intro/howto.html#3">17</a>,
<a href="../23_containers/howto.html#3">23</a> and