gcc/libstdc++-v3/docs/html/17_intro/howto.html

190 lines
9.1 KiB
HTML
Raw Normal View History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)">
<meta name="KEYWORDS" content="HOWTO, libstdc++, gcc, g++, libg++, STL">
<meta name="DESCRIPTION" content="HOWTO for libstdc++ chapter 17.">
<meta name="GENERATOR" content="vi and eight fingers">
<title>libstdc++-v3 HOWTO: Chapter 17</title>
<link rel="StyleSheet" href="../lib3styles.css">
</head>
<body>
<h1 class="centered"><a name="top">Chapter 17: Library Introduction</a></h1>
<p>Chapter 17 is actually a list of definitions and descriptions used
in the following chapters of the Standard when describing the actual
library. Here, we use &quot;Introduction&quot; as an introduction
to the <em>GNU implementation of</em> the ISO Standard C++ Library.
</p>
<!-- ####################################################### -->
<hr>
<h1>Contents</h1>
<ul>
<li><a href="#2">The Standard C++ header files</a>
<li><a href="#3">Thread-safety</a>
<li><a href="#4"><code>&lt;foo&gt;</code> vs <code>&lt;foo.h&gt;</code></a>
<li><a href="porting-howto.html">Porting HOWTO</a>
</ul>
<hr>
<!-- ####################################################### -->
<h2><a name="2">The Standard C++ header files</a></h2>
<p>The Standard C++ Library specifies 50 header files that must be
available to all hosted implementations. Actually, the word
&quot;files&quot; is a misnomer, since the contents of the headers
don't necessarily have to be in any kind of external file. The
only rule is that when you <code>#include</code> a certain header, the
contents of that header, as defined by the Standard, become
available to you, no matter how.
</p>
<p>The names of the headers can be easily seen in
<a href="headers_cc.txt"><code>testsuite/17_intro/headers.cc</code></a>,
which is a small testbed we use to make certain that the headers
all compile and run.
</p>
<hr>
<h2><a name="3">Thread-safety</a></h2>
<p>This is a thorny issue that gets brought up on the libstdc++-v3
and gcc mailing lists on a regular basis (probably by a cron job).
This entry will mention a very little bit about the general MT
issues with libstdc++. The latest status and quick notes will be
in FAQ 5.6. Some discussion about thread-safe containers will be
threads-no.h: Remove file. * config/threads-no.h: Remove file. * config/threads-posix.h: Remove file. * acconfig.h (_GLIBCPP_USE_THREADS): Remove. (_GLIBCPP_SUPPORTS_WEAK): Add (required by namespace-clean gthr*.h). (_GLIBCPP_HAVE_GTHR_DEFAULT): Likewise. * config.h.in: Regenerate. * acinclude.m4 (GLIBCPP_ENABLE_THREADS): Completely rework to setup and use gthr*.h files. In particular, make gthr.h files namespace-clean in the staging area (they don't have to be for libgcc.a). * aclocal.m4: Regenerate. * configure: Regenerate. * src/Makefile.am (build_headers): Remove bits/c++threads.h and add bits/gthr.h bits/gthr-single.h bits/gthr-default.h. * src/Makefile.in: Regenerate. * include/bits/c++config: Cleanup threading configuration macros. In particular, define __STL_GTHREADS macro which controls... * include/bits/stl_threads.h: ...a brand new gthr.h-based configuration here. * config/c_io_stdio.h: Include staged gthr.h instead of local thread configuration file. Always use __gthread_mutex_t instead of __mutext_type (or int). * include/bits/std_fstream.h: Likewise. * docs/html/17_intro/howto.html: Remove placeholder comment in case this configuration patch didn't make it. Add advice that section only applies if configured with --enable-threads. * docs/html/23_containers/howto.html: Reword to make clear that _PTHREADS is no longer required for any port to be correctly using STL with threads. Add advice that section only applies if configured with --enable-threads. Co-Authored-By: John David Anglin <dave@hiauly1.hia.nrc.ca> From-SVN: r42998
2001-06-08 11:53:35 +08:00
in section 6.8 (the HOWTOs on containers). This section only applies
when gcc and libstdc++-v3 were configured with --enable-threads.
</p>
<p>The libstdc++ code (all of it, not just the containers) has been
designed so that thread-safety will be easily possible. The first
(!) problem is finding a <em>fast</em> method of implementation
portable to all platforms. A minor problem that pops up every so
often is different interpretations of what &quot;thread-safe&quot;
means for a library (not a general program). We currently use the
<a href="http://www.sgi.com/tech/stl/thread_safety.html">same
definition that SGI</a> uses for their STL subset.
<em>Please see the many cautions given in HOWTOs on containers.</em>
</p>
<p>Here is another attempt at explaining the dangers of using the
STL with threading support without understanding some important
details. The STL implementation is currently configured to use
the high-speed caching memory allocator. If you absolutely
think you must change this on a global basis for your platform
to support multi-threading, then please consult all commentary
in include/bits/c++config and the HOWTOs on containers. Be
fully aware that you may change the external or internal ABI of
libstdc++-v3 when you provide -D__USE_MALLOC on the command line
threads-no.h: Remove file. * config/threads-no.h: Remove file. * config/threads-posix.h: Remove file. * acconfig.h (_GLIBCPP_USE_THREADS): Remove. (_GLIBCPP_SUPPORTS_WEAK): Add (required by namespace-clean gthr*.h). (_GLIBCPP_HAVE_GTHR_DEFAULT): Likewise. * config.h.in: Regenerate. * acinclude.m4 (GLIBCPP_ENABLE_THREADS): Completely rework to setup and use gthr*.h files. In particular, make gthr.h files namespace-clean in the staging area (they don't have to be for libgcc.a). * aclocal.m4: Regenerate. * configure: Regenerate. * src/Makefile.am (build_headers): Remove bits/c++threads.h and add bits/gthr.h bits/gthr-single.h bits/gthr-default.h. * src/Makefile.in: Regenerate. * include/bits/c++config: Cleanup threading configuration macros. In particular, define __STL_GTHREADS macro which controls... * include/bits/stl_threads.h: ...a brand new gthr.h-based configuration here. * config/c_io_stdio.h: Include staged gthr.h instead of local thread configuration file. Always use __gthread_mutex_t instead of __mutext_type (or int). * include/bits/std_fstream.h: Likewise. * docs/html/17_intro/howto.html: Remove placeholder comment in case this configuration patch didn't make it. Add advice that section only applies if configured with --enable-threads. * docs/html/23_containers/howto.html: Reword to make clear that _PTHREADS is no longer required for any port to be correctly using STL with threads. Add advice that section only applies if configured with --enable-threads. Co-Authored-By: John David Anglin <dave@hiauly1.hia.nrc.ca> From-SVN: r42998
2001-06-08 11:53:35 +08:00
or make a change to that configuration file.
</p>
<p>If you don't like caches of objects being retained inside the STL, then
you might be tempted to define __USE_MALLOC either on the command
line or by rebuilding c++config.h. Please note, once you define
__USE_MALLOC, only the malloc allocator is visible to application code
(i.e. the typically higher-speed allocator is not even available
in this configuration). There is a better way: It is possible
to force the malloc-based allocator on a per-case-basis for some
application code even when the above macro symbol is not defined.
The library team generally believes that this is a better way to tune
an application for high-speed using this implementation of the STL.
Here is one possible example displaying the forcing of the malloc-based
allocator over the typically higher-speed default allocator:
<pre>
std::list &lt;my_type, std::malloc_alloc&gt; my_malloc_based_list;</pre>
</p>
<p>A recent journal article has described &quot;atomic integer
operations,&quot; which would allow us to, well, perform updates
on integers atomically, and without requiring an explicit mutex
lock. This appears promising, but the major difficulty is that
these operations &quot;may not be available on all systems, and
if they are, may have different interfaces.&quot; [quoting from
mailing list messages]
</p>
<p>Here is a small link farm to threads (no pun) in the mail archives
that discuss the threading problem. Each link is to the first
relevent message in the thread; from there you can use
&quot;Thread Next&quot; to move down the thread. This farm is in
latest-to-oldest order.
<ul>
<li><a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html">
inspired this most recent updating of issues with threading
and the SGI STL library. It also contains some example
POSIX-multithreaded STL code.</a>
<li> <a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">
an early analysis of why __USE_MALLOC should be disabled 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>
</p>
<p>This section will be updated as new and interesting issues come
to light.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr>
<h2><a name="4"><code>&lt;foo&gt;</code> vs <code>&lt;foo.h&gt;</code></a></h2>
<p>The new-style headers are fully supported in libstdc++-v3. The compiler
itself fully supports namespaces, including <code>std::</code>.
</p>
<p>For those of you new to ISO C++98, no, that isn't a typo, the headers
really have new names. Marshall Cline's C++ FAQ Lite has a good
explanation in
<a href="http://www.cerfnet.com/~mpcline/On-Line-C++-FAQ/coding-standards.html#[25.4]">item [25.4]</a>.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<!-- ####################################################### -->
<hr>
<p class="fineprint"><em>
See <a href="license.html">license.html</a> for copying conditions.
Comments and suggestions are welcome, and may be sent to
<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
</em></p>
</body>
</html>