From aa2a8516ce528253bf241f1730876c904823e469 Mon Sep 17 00:00:00 2001 From: Phil Edwards Date: Wed, 17 Oct 2001 18:14:58 +0000 Subject: [PATCH] howto.html: Remove 1999 links (and explain why). 2001-10-17 Phil Edwards * 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 
	markup.
	* docs/html/faq/index.txt:  Regenerate.

From-SVN: r46321
---
 libstdc++-v3/ChangeLog                     |  8 +++
 libstdc++-v3/docs/html/17_intro/howto.html | 52 +++++-----------
 libstdc++-v3/docs/html/faq/index.html      | 71 +++++++++++-----------
 libstdc++-v3/docs/html/faq/index.txt       | 52 ++++++++++++----
 4 files changed, 97 insertions(+), 86 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 808d1f07420..32f6c21208a 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,11 @@
+2001-10-17  Phil Edwards  
+
+	* 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 
+	markup.
+	* docs/html/faq/index.txt:  Regenerate.
+
 2001-10-12  Loren J. Rittle  
 
 	* docs/html/faq/index.html (Is libstdc++-v3 thread-safe?): Update
diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html
index d7ca3f3f274..69d9886887f 100644
--- a/libstdc++-v3/docs/html/17_intro/howto.html
+++ b/libstdc++-v3/docs/html/17_intro/howto.html
@@ -67,7 +67,8 @@
       means for a library (not a general program).  We currently use the
       same
       definition that SGI uses for their STL subset.
-      Please see the many cautions given in HOWTOs on containers.
+      Please see the many cautions given in
+      HOWTOs on containers.
    

    
Here is another attempt at explaining the dangers of using the
       STL with threading support without understanding some important
@@ -109,46 +110,21 @@
       "Thread Next" to move down the thread.  This farm is in
       latest-to-oldest order.
       

-      

-      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.)
-      

-      
    
-        
  • One way of preventing memory leaks by the old default memory
-            allocator in multithreaded code is
-            discussed here.
-        
  • This thread
-            concerns strings.
-        
  • So does this
-            one.  This initial message also refers to another
-            thread in the GCC mailing list...
-        
  • which is here,
-            and goes on for some time.  Ironically, the initial message
-            in this thread also mentions another threading thread...
-        
  • beginning here,
-            and talking about pthreads.  (Note that a much more recent
-            message from the first thread in this list notes that
-            pthreads
-            should not be used as a starting point for making
-            libstdc++ threadsafe.)
-        
  • This
-            message,
-            this one,
-            and this one
-            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.
+        POSIX-multithreaded STL code.
+        
  • 
+        Here is an early analysis of why __USE_MALLOC should be disabled
+        for the 3.0 release of libstdc++.
       

+      (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.)
    

    
This section will be updated as new and interesting issues come
       to light.
diff --git a/libstdc++-v3/docs/html/faq/index.html b/libstdc++-v3/docs/html/faq/index.html
index e0f31ceba3e..650a5ec700a 100644
--- a/libstdc++-v3/docs/html/faq/index.html
+++ b/libstdc++-v3/docs/html/faq/index.html
@@ -687,49 +687,46 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
 

    
5.6 Is libstdc++-v3 thread-safe?

       
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
+         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:
-      

+         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;
+     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
-       }
+     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.
-         

-      
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:
+     // 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 17,
-         23 and
-	 27 for more information.
+     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 17 (library + introduction), 23 + (containers), and 27 (I/O) for + more information.

diff --git a/libstdc++-v3/docs/html/faq/index.txt b/libstdc++-v3/docs/html/faq/index.txt index fcf84c8cd83..44c4748083c 100644 --- a/libstdc++-v3/docs/html/faq/index.txt +++ b/libstdc++-v3/docs/html/faq/index.txt @@ -548,15 +548,45 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff 5.6 Is libstdc++-v3 thread-safe? - Quick answer: no, as of 3.0, most of the library is not safe for - multithreaded access. The string class is MT-safe. - - This is assuming that your idea of "multithreaded" is the same as - ours... The general question of multithreading and libstdc++-v3 is - addressed in the chapter-specific advice for [80]Library Introduction. - Threadsafe containers are covered in more detail in [81]the Received - Wisdom section on containers. Threading and I/O are discussed in - [82]the I/O chapter. + 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 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; + + 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. + + 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? @@ -660,8 +690,8 @@ References 78. http://www.sgi.com/Technology/STL/ 79. ../ext/howto.html 80. ../17_intro/howto.html#3 - 81. ../23_containers/howto.html - 82. ../27_io/howto.html + 81. ../23_containers/howto.html#3 + 82. ../27_io/howto.html#9 83. http://www.ansi.org/ 84. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998 85. http://www.iso.ch/ -- 2.30.2