howto.html: Remove 1999 links (and explain why).
2001-10-17 Phil Edwards <pme@gcc.gnu.org> * docs/html/17_intro/howto.html: Remove 1999 links (and explain why). Add link to recent message. * docs/html/faq/index.html (5.6): Reformat text only; fixup <pre> markup. * docs/html/faq/index.txt: Regenerate. From-SVN: r46321
This commit is contained in:
Phil Edwards
parent
a4f6c31268
commit
aa2a8516ce
4 changed files with 97 additions and 86 deletions
|
|
@ -1,3 +1,11 @@
|
||||||
|
2001-10-17 Phil Edwards <pme@gcc.gnu.org>
|
||||||
|
|
||||||
|
* docs/html/17_intro/howto.html: Remove 1999 links (and explain
|
||||||
|
why). Add link to recent message.
|
||||||
|
* docs/html/faq/index.html (5.6): Reformat text only; fixup <pre>
|
||||||
|
markup.
|
||||||
|
* docs/html/faq/index.txt: Regenerate.
|
||||||
|
|
||||||
2001-10-12 Loren J. Rittle <ljrittle@acm.org>
|
2001-10-12 Loren J. Rittle <ljrittle@acm.org>
|
||||||
|
|
||||||
* docs/html/faq/index.html (Is libstdc++-v3 thread-safe?): Update
|
* docs/html/faq/index.html (Is libstdc++-v3 thread-safe?): Update
|
||||||
|
|
|
||||||
|
|
@ -67,7 +67,8 @@
|
||||||
means for a library (not a general program). We currently use the
|
means for a library (not a general program). We currently use the
|
||||||
<a href="http://www.sgi.com/tech/stl/thread_safety.html">same
|
<a href="http://www.sgi.com/tech/stl/thread_safety.html">same
|
||||||
definition that SGI</a> uses for their STL subset.
|
definition that SGI</a> uses for their STL subset.
|
||||||
<em>Please see the many cautions given in HOWTOs on containers.</em>
|
<em>Please see the many cautions given in
|
||||||
|
<a href="../23_containers/howto.html">HOWTOs on containers</a>.</em>
|
||||||
</p>
|
</p>
|
||||||
<p>Here is another attempt at explaining the dangers of using the
|
<p>Here is another attempt at explaining the dangers of using the
|
||||||
STL with threading support without understanding some important
|
STL with threading support without understanding some important
|
||||||
|
|
@ -109,46 +110,21 @@
|
||||||
"Thread Next" to move down the thread. This farm is in
|
"Thread Next" to move down the thread. This farm is in
|
||||||
latest-to-oldest order.
|
latest-to-oldest order.
|
||||||
<ul>
|
<ul>
|
||||||
|
<li>Our threading expert Loren gives a breakdown of
|
||||||
|
<a href="http://gcc.gnu.org/ml/libstdc++/2001-10/msg00024.html">the
|
||||||
|
six situations involving threads</a> for the 3.0 release series.
|
||||||
<li><a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html">
|
<li><a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html">
|
||||||
inspired this most recent updating of issues with threading
|
This message</a> inspired a recent updating of issues with threading
|
||||||
and the SGI STL library. It also contains some example
|
and the SGI STL library. It also contains some example
|
||||||
POSIX-multithreaded STL code.</a>
|
POSIX-multithreaded STL code.
|
||||||
<li> <a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">
|
<li><a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">
|
||||||
an early analysis of why __USE_MALLOC should be disabled for
|
Here</a> is an early analysis of why __USE_MALLOC should be disabled
|
||||||
the 3.0 release of libstdc++.</a>
|
for the 3.0 release of libstdc++.</a>
|
||||||
</ul>
|
|
||||||
<br>
|
|
||||||
Here are discussions that took place before the current snapshot;
|
|
||||||
they are still relevant and instructive. (Some of them may not work;
|
|
||||||
as the drive containing some of the 1999 archives crashed, and nobody
|
|
||||||
has had time to recover the backups.)
|
|
||||||
<br>
|
|
||||||
<ul>
|
|
||||||
<li>One way of preventing memory leaks by the old default memory
|
|
||||||
allocator in multithreaded code is
|
|
||||||
<a href="http://gcc.gnu.org/ml/gcc/1999-11n/msg00431.html">discussed here</a>.
|
|
||||||
<li><a href="http://gcc.gnu.org/ml/libstdc++/1999-q3/msg00167.html">This thread
|
|
||||||
concerns strings</a>.
|
|
||||||
<li><a href="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00339.html">So does this
|
|
||||||
one</a>. This initial message also refers to another
|
|
||||||
thread in the GCC mailing list...
|
|
||||||
<li><a href="http://gcc.gnu.org/ml/gcc/1999-06n/msg00680.html">which is here</a>,
|
|
||||||
and goes on for some time. Ironically, the initial message
|
|
||||||
in this thread also mentions another threading thread...
|
|
||||||
<li><a href="http://gcc.gnu.org/ml/gcc-bugs/1999-04n/msg00777.html">beginning here</a>,
|
|
||||||
and talking about pthreads. (Note that a much more recent
|
|
||||||
message from the first thread in this list notes that
|
|
||||||
<a href="http://gcc.gnu.org/ml/libstdc++/1999-q3/msg00176.html">pthreads
|
|
||||||
should not be used as a starting point</a> for making
|
|
||||||
libstdc++ threadsafe.)
|
|
||||||
<li><a href="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00168.html">This
|
|
||||||
message</a>,
|
|
||||||
<a href="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00159.html">this one</a>,
|
|
||||||
and <a href="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00156.html">this one</a>
|
|
||||||
are the tops of related threads (all within the same time
|
|
||||||
period) discussing threading and the IO library. Much of it
|
|
||||||
is dealing with the C library, but C++ is included as well.
|
|
||||||
</ul>
|
</ul>
|
||||||
|
(A large selection of links to older messages has been removed; many
|
||||||
|
of the messages from 1999 were lost in a disk crash, and the few
|
||||||
|
people with access to the backup tapes have been too swamped with work
|
||||||
|
to restore them. Many of the points have been superceded anyhow.)
|
||||||
</p>
|
</p>
|
||||||
<p>This section will be updated as new and interesting issues come
|
<p>This section will be updated as new and interesting issues come
|
||||||
to light.
|
to light.
|
||||||
|
|
|
||||||
|
|
@ -687,49 +687,46 @@ 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, a non-generic
|
<p>When the system's libc is itself thread-safe, a non-generic
|
||||||
implementation of atomicity.h exists for the architecture, and
|
implementation of atomicity.h exists for the architecture, and gcc
|
||||||
gcc itself reports a thread model other than single; libstdc++-v3
|
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
|
||||||
library object's state. Typically, the application
|
object's state. Typically, the application programmer may infer
|
||||||
programmer may infer what object locks must be held based on
|
what object locks must be held based on the objects referenced in
|
||||||
the objects referenced in a method call. Without getting
|
a method call. Without getting into great detail, here is an
|
||||||
into great detail, here is an example which requires
|
example which requires user-level locks:
|
||||||
|
<pre>
|
||||||
|
library_class_a shared_object_a;
|
||||||
|
|
||||||
|
thread_main () {
|
||||||
|
library_class_b *object_b = new library_class_b;
|
||||||
|
shared_object_a.add_b (object_b); // must hold lock for shared_object_a
|
||||||
|
shared_object_a.mutate (); // must hold lock for shared_object_a
|
||||||
|
}
|
||||||
|
|
||||||
|
// Multiple copies of thread_main() are started in independent threads.</pre>
|
||||||
|
</p>
|
||||||
|
<p>Under the assumption that object_a and object_b are never exposed to
|
||||||
|
another thread, here is an example that should not require any
|
||||||
user-level locks:
|
user-level locks:
|
||||||
</p>
|
|
||||||
<pre>
|
<pre>
|
||||||
library_class_a shared_object_a;
|
thread_main () {
|
||||||
|
library_class_a object_a;
|
||||||
thread_main () {
|
library_class_b *object_b = new library_class_b;
|
||||||
library_class_b *object_b = new library_class_b;
|
object_a.add_b (object_b);
|
||||||
shared_object_a.add_b (object_b); // must hold lock for shared_object_a
|
object_a.mutate ();
|
||||||
shared_object_a.mutate (); // must hold lock for shared_object_a
|
} </pre>
|
||||||
}
|
|
||||||
|
|
||||||
// Multiple copies of thread_main() are started in independent threads.
|
|
||||||
</pre>
|
|
||||||
<p>Under the assumption that object_a and object_b are never
|
|
||||||
exposed to another thread, here is an example that should not
|
|
||||||
require any user-level locks:
|
|
||||||
</p>
|
</p>
|
||||||
<pre>
|
<p>All library objects are safe to use in a multithreaded program as
|
||||||
thread_main () {
|
long as each thread carefully locks out access by any other thread
|
||||||
library_class_a object_a;
|
while it uses any object visible to another thread. This requirement
|
||||||
library_class_b *object_b = new library_class_b;
|
includes both read and write access to objects; do not assume that
|
||||||
object_a.add_b (object_b);
|
two threads may read a shared standard container at the same time.
|
||||||
object_a.mutate ();
|
|
||||||
}
|
|
||||||
</pre>
|
|
||||||
<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>
|
||||||
<p>See chapters <a href="../17_intro/howto.html#3">17</a>,
|
<p>See chapters <a href="../17_intro/howto.html#3">17</a> (library
|
||||||
<a href="../23_containers/howto.html#3">23</a> and
|
introduction), <a href="../23_containers/howto.html#3">23</a>
|
||||||
<a href="../27_io/howto.html#9">27</a> for more information.
|
(containers), and <a href="../27_io/howto.html#9">27</a> (I/O) for
|
||||||
|
more information.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<hr>
|
<hr>
|
||||||
|
|
|
||||||
|
|
@ -548,15 +548,45 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
||||||
|
|
||||||
5.6 Is libstdc++-v3 thread-safe?
|
5.6 Is libstdc++-v3 thread-safe?
|
||||||
|
|
||||||
Quick answer: no, as of 3.0, most of the library is not safe for
|
When the system's libc is itself thread-safe, a non-generic
|
||||||
multithreaded access. The string class is MT-safe.
|
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 programmer may infer what object locks must
|
||||||
|
be held based on the objects referenced in a method call. Without
|
||||||
|
getting into great detail, here is an example which requires
|
||||||
|
user-level locks:
|
||||||
|
library_class_a shared_object_a;
|
||||||
|
|
||||||
This is assuming that your idea of "multithreaded" is the same as
|
thread_main () {
|
||||||
ours... The general question of multithreading and libstdc++-v3 is
|
library_class_b *object_b = new library_class_b;
|
||||||
addressed in the chapter-specific advice for [80]Library Introduction.
|
shared_object_a.add_b (object_b); // must hold lock for shared_object_
|
||||||
Threadsafe containers are covered in more detail in [81]the Received
|
a
|
||||||
Wisdom section on containers. Threading and I/O are discussed in
|
shared_object_a.mutate (); // must hold lock for shared_object_
|
||||||
[82]the I/O chapter.
|
a
|
||||||
|
}
|
||||||
|
|
||||||
|
// Multiple copies of thread_main() are started in independent threads.
|
||||||
|
|
||||||
|
Under the assumption that object_a and object_b are never exposed to
|
||||||
|
another thread, here is an example that should not require any
|
||||||
|
user-level locks:
|
||||||
|
thread_main () {
|
||||||
|
library_class_a object_a;
|
||||||
|
library_class_b *object_b = new library_class_b;
|
||||||
|
object_a.add_b (object_b);
|
||||||
|
object_a.mutate ();
|
||||||
|
}
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
See chapters [80]17 (library introduction), [81]23 (containers), and
|
||||||
|
[82]27 (I/O) for more information.
|
||||||
_________________________________________________________________
|
_________________________________________________________________
|
||||||
|
|
||||||
5.7 How do I get a copy of the ISO C++ Standard?
|
5.7 How do I get a copy of the ISO C++ Standard?
|
||||||
|
|
@ -660,8 +690,8 @@ References
|
||||||
78. http://www.sgi.com/Technology/STL/
|
78. http://www.sgi.com/Technology/STL/
|
||||||
79. ../ext/howto.html
|
79. ../ext/howto.html
|
||||||
80. ../17_intro/howto.html#3
|
80. ../17_intro/howto.html#3
|
||||||
81. ../23_containers/howto.html
|
81. ../23_containers/howto.html#3
|
||||||
82. ../27_io/howto.html
|
82. ../27_io/howto.html#9
|
||||||
83. http://www.ansi.org/
|
83. http://www.ansi.org/
|
||||||
84. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
|
84. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
|
||||||
85. http://www.iso.ch/
|
85. http://www.iso.ch/
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue