Skip to content

R
riscv-gcc-1
Commit 79e79067 by Benjamin Kosnik Committed by Benjamin Kosnik
Options

howto.html: Update. 

2007-12-09  Benjamin Kosnik  <bkoz@redhat.com>

	* docs/html/ext/howto.html: Update.
	* docs/html/ext/sgiexts.html: Same.
	* docs/html/ext/concurrence.html: New. Document extensions.
	* docs/html/17_intro/api.html: Move some bits...
	* docs/html/17_intro/backwards_compatibility.html: here. New. Add
	compatibility suggestions, move existing ones.
	* docs/html/17_intro/howto.html: Update info.
	* docs/html/18_support/howto.html: Tweak.
	* docs/html/faq/index.html: Update thread info.
	* docs/html/documentation.html: Add links.
	* docs/html/20_util/allocator.html: Update info.
	* include/precompiled/stdc++.h: Add C++0x includes if appropriate.
	* testsuite/17_intro/headers/c++200x/all.cc: Same.

From-SVN: r130732
parent 6e221515
Showing with 499 additions and 80 deletions
libstdc++-v3/ChangeLog
2007-12-09 Benjamin Kosnik <bkoz@redhat.com>
* docs/html/ext/howto.html: Update.
* docs/html/ext/sgiexts.html: Same.
* docs/html/ext/concurrence.html: New. Document extensions.
* docs/html/17_intro/api.html: Move some bits...
* docs/html/17_intro/backwards_compatibility.html: here. New. Add
compatibility suggestions, move existing ones.
* docs/html/17_intro/howto.html: Update info.
* docs/html/18_support/howto.html: Tweak.
* docs/html/faq/index.html: Update thread info.
* docs/html/documentation.html: Add links.
* docs/html/20_util/allocator.html: Update info.
* include/precompiled/stdc++.h: Add C++0x includes if appropriate.
* testsuite/17_intro/headers/c++200x/all.cc: Same.
2007-12-09 Jonathan Wakely <jwakely.gcc@gmail.com>
* testsuite/util/testsuite_allocator.h,
......
libstdc++-v3/docs/html/18_support/howto.html
......@@ -281,9 +281,6 @@
</p>
<pre>
std::set_terminate(std::abort);</pre>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<p>
This function will attempt to write to stderr. If your application
......@@ -292,6 +289,11 @@
unspecified manner.
</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="5">Dynamic memory management</a></h2>
<p>There are six flavors each of <code>new</code> and
......
libstdc++-v3/docs/html/20_util/allocator.html
......@@ -84,34 +84,47 @@
</h3>
<p>The easiest way of fulfilling the requirements is to call operator new
each time a container needs memory, and to call operator delete each
time the container releases memory. <strong>BUT</strong>
<a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00105.html">this
method is horribly slow</a>.
</p>
<p>Or we can keep old memory around, and reuse it in a pool to save time.
The old libstdc++-v2 used a memory pool, and so do we. As of 3.0,
<a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">it's
on by default</a>. The pool is shared among all the containers in the
program: when your program's std::vector&lt;int&gt; gets cut in half
and frees a bunch of its storage, that memory can be reused by the
private std::list&lt;WonkyWidget&gt; brought in from a KDE library
that you linked against. And we don't have to call operators new and
delete to pass the memory on, either, which is a speed bonus.
<strong>BUT</strong>...
</p>
<p>What about threads? No problem: in a threadsafe environment, the
memory pool is manipulated atomically, so you can grow a container in
one thread and shrink it in another, etc. <strong>BUT</strong> what
if threads in libstdc++ aren't set up properly?
<a href="../faq/index.html#5_6">That's been answered already</a>.
</p>
<p><strong>BUT</strong> what if you want to use your own allocator? What
if you plan on using a runtime-loadable version of malloc() which uses
shared telepathic anonymous mmap'd sections serializable over a
network, so that memory requests <em>should</em> go through malloc?
And what if you need to debug it?
</p>
time the container releases memory. This method may be
<a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00105.html">slower</a>
than caching the allocations and re-using previously-allocated
memory, but has the advantage of working correctly across a wide
variety of hardware and operating systems, including large
clusters. The <code>__gnu_cxx::new_allocator</code> implements
the simple operator new and operator delete semantics, while <code>__gnu_cxx::malloc_allocator</code> implements much the same thing, only with the C language functions <code>std::malloc</code> and <code>std::free</code>.
</p>
<p> Another approach is to use intelligence within the allocator class
to cache allocations. This extra machinery can take a variety of
forms: a bitmap index, an index into an exponentially increasing
power-of-two-sized buckets, or simpler fixed-size pooling cache. The
cache is shared among all the containers in the program: when your
program's std::vector&lt;int&gt; gets cut in half and frees a bunch of
its storage, that memory can be reused by the private
std::list&lt;WonkyWidget&gt; brought in from a KDE library that you
linked against. And operators new and delete are not always called to
pass the memory on, either, which is a speed bonus. Examples of
allocators that use these techniques
are <code>__gnu_cxx::bitmap_allocator</code>, <code>__gnu_cxx::pool_allocator</code>,
and <code>__gnu_cxx::__mt_alloc</code>.
</p>
<p>Depending on the implementation techniques used, the underlying
operating system, and compilation environment, scaling caching
allocators can be tricky. In particular, order-of-destruction and
order-of-creation for memory pools may be difficult to pin down with
certainty, which may create problems when used with plugins or loading
and unloading shared objects in memory. As such, using caching
allocators on systems that do not
support <code>abi::__cxa_atexit</code> is not recommended.
</p>
<p>Versions of libstdc++ prior to 3.4 cache allocations in a memory
pool, instead of passing through to call the global allocation
operators (ie, <code>__gnu_cxx::pool_allocator</code>). More
recent versions default to the
simpler <code>__gnu_cxx::new_allocator</code>.
</p>
<h3 class="left">
<a name="stdallocator">Implementation details of <code>std::allocator</code></a>
</h3>
......@@ -335,6 +348,11 @@
<td>&lt;ext/array_allocator.h&gt;</td>
<td>4.0.0</td>
</tr>
<tr>
<td>__gnu_cxx::throw_allocator&lt;T&gt;</td>
<td>&lt;ext/throw_allocator.h&gt;</td>
<td>4.2.0</td>
</tr>
</table>
<p>More details on each of these extension allocators follows. </p>
......@@ -371,6 +389,12 @@
size is checked, and assert() is used to guarantee they match.
</p>
</li>
<li><code>throw_allocator</code>
<p> Includes memory tracking and marking abilities as well as hooks for
throwing exceptinos at configurable intervals (including random,
all, none).
</p>
</li>
<li><code>__pool_alloc</code>
<p> A high-performance, single pool allocator. The reusable
memory is shared among identical instantiations of this type.
......
libstdc++-v3/docs/html/documentation.html
......@@ -26,7 +26,7 @@ href="http://gcc.gnu.org/libstdc++">project</a> to implement the ISO
annex D, extensions as described by TR1, and future C++ library
standards still in progress. For those who want to see exactly how far
the project has come, or just want the latest bleeding-edge code, the
up-to-date source is always publically available over anonymous SVN,
up-to-date source is always publicly available over anonymous SVN,
and can be browsed over the <a
href="http://gcc.gnu.org/svn.html">web</a>.
</p>
......@@ -34,13 +34,6 @@ href="http://gcc.gnu.org/svn.html">web</a>.
<p>Stable versions of libstdc++ are included with releases of
<a href="http://gcc.gnu.org/releases.html">the GCC compilers</a>.
</p>
<!--
The list below is automatically generated. To make changes in the text,
edit the appropriate HOWTO file and run "make" in this directory. In
those files, you may reorder entries as you like, but DO NOT change the
"#number"s in anchors, for they are used elsewhere and in bookmarks.
-->
<!-- beginlist -->
<ul>
<li>Introduction
<ul>
......@@ -77,26 +70,27 @@ href="http://gcc.gnu.org/svn.html">web</a>.
<ul>
<li>Header Files
<ul>
<li><a href="17_intro/howto.html#2.1">Available headers</a></li>
<li><a href="17_intro/howto.html#2.2">Headers and <code>namespace std</code></a></li>
<li>Pre-compiled headers</li>
<li><a href="17_intro/howto.html#2.0">Available headers</a></li>
<li><a href="17_intro/howto.html#2.1">Mixing headers</a></li>
<li><a href="17_intro/howto.html#2.2">The C Headers and <code>namespace std</code></a></li>
<li><a href="17_intro/howto.html#2.3">Precompiled Headers</a></li>
</ul>
</li>
<li>Namespaces
<ul>
<li><a href="17_intro/howto.html#2.5">Namespace <code>std::</code></a></li>
<li><a href="17_intro/howto.html#2.6">Using namespace composition</a></li>
<li><a href="17_intro/howto.html#3.0">Available namespaces</li>
<li><a href="17_intro/howto.html#3.1">Namespace <code>std::</code></a></li>
<li><a href="17_intro/howto.html#3.2">Using namespace composition</a></li>
</ul>
</li>
<li><a href="17_intro/howto.html#6">Macros</a></li>
<li>Command line options</li>
<li>Concurrency
<ul>
<li>Atomic Operations</li>
<li><a href="17_intro/howto.html#3">Thread safety overview</a></li>
<li><a href="faq/index.html#5_6">Is it thread safe?</a></li>
<li><a href="17_intro/howto.html#7">Thread safety history and evolution</a></li>
<li><a href="23_containers/howto.html#3">Containers</a></li>
<li><a href="27_io/howto.html#9">IO</a></li>
</ul>
......@@ -122,8 +116,15 @@ href="http://gcc.gnu.org/svn.html">web</a>.
<li>Diagnostics
<ul>
<li>Exceptions
<ul>
<li>Exception class hierarchy</li>
<li><a href="19_diagnostics/howto.html#1">Adding data to exceptions</a></li>
<li>Cancellation</li>
</ul>
</li>
<li><a href="19_diagnostics/howto.html#3">Concept checking</a></li>
</ul>
</li>
......@@ -248,6 +249,7 @@ href="http://gcc.gnu.org/svn.html">web</a>.
</ul>
</li>
<li><a href="ext/../18_support/howto.html#6">Demangling</a></li>
<li><a href="ext/concurrence.html">Concurrency: Threads and Atomics</a></li>
</ul>
</li>
......@@ -277,6 +279,7 @@ href="http://gcc.gnu.org/svn.html">web</a>.
<li><a href="17_intro/porting.html">Porting to new hardware or operating systems.</a></li>
<li><a href="17_intro/abi.html">ABI Policy and Guidelines</a></li>
<li><a href="17_intro/api.html">API Evolution and Deprecation History</a></li>
<li><a href="17_intro/backwards_compatibility.html">Backwards Compatibility</a></li>
</ul>
</li>
......
libstdc++-v3/docs/html/ext/concurrence.html 0 → 100644
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="bkoz@gcc.gnu.org (Benjamin Kosnik)" />
<meta name="KEYWORDS" content="C++, libstdc++, MT, thread, pthread, mutex, loc, atomic" />
<meta name="DESCRIPTION" content="Concurrency Support" />
<meta name="GENERATOR" content="emacs and ten fingers" />
<title>Concurrency Support</title>
<link rel="StyleSheet" href="lib3styles.css" type="text/css" />
<link rel="Start" href="documentation.html" type="text/html"
title="GNU C++ Standard Library" />
<link rel="Copyright" href="17_intro/license.html" type="text/html" />
</head>
<body>
<h1 class="centered"><a name="top">Concurrency Support</a></h1>
<p class="fineprint"><em>
The latest version of this document is always available at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/concurrence.html">
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/concurrence.html</a>.
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
<hr />
<p>The interface for concurrency support is divided into two files:
&lt;ext/atomicity.h&gt; which provides support for atomic operations,
and &lt;ext/concurrence.h&gt;, which provides mutex and lock objects
as well as compile-time data structures for querying thread
support.</p>
<p>It is expected that support for concurrence will evolve into what
is specified in the draft C++0x standard.</p>
<h3 class="left">
<a name="atomic_api">Atomics Interface</a>
</h3>
<p>
Two functions and one type form the base of atomic support.
</p>
<p>The type <code>_Atomic_word</code> is a signed integral type
supporting atomic operations.
</p>
<p>
The two functions functions are:
</p>
<pre>
_Atomic_word
__exchange_and_add_dispatch(volatile _Atomic_word*, int);
void
__atomic_add_dispatch(volatile _Atomic_word*, int);
</pre>
<p>Both of these functions are declared in the header file
&lt;ext/atomicity.h&gt;, and are in <code>namespace __gnu_cxx</code>.
</p>
<ul>
<li>
<code>
__exchange_and_add_dispatch
</code>
<p>Adds the second argument's value to the first argument. Returns the old value.
</p>
</li>
<li>
<code>
__atomic_add_dispatch
</code>
<p>Adds the second argument's value to the first argument. Has no return value.
</p>
</li>
</ul>
</p>
These functions forward to one of several specialized helper
functions, depending on the circumstances. For instance,
</p>
<p>
<code>
__exchange_and_add_dispatch
</code>
</p>
<p>
Calls through to either of:
</p>
<ul>
<li><code>__exchange_and_add</code>
<p>Multi-thread version. Inlined if compiler-generated builtin atomics
can be used, otherwise resolved at link time to a non-builtin code
sequence.
</p>
</li>
<li><code>__exchange_and_add_single</code>
<p>Single threaded version. Inlined.</p>
</li>
</ul>
<p>However, only <code>__exchange_and_add_dispatch</code>
and <code>__atomic_add_dispatch</code> should be used. These functions
can be used in a portable manner, regardless of the specific
environment. They are carefully designed to provide optimum efficiency
and speed, abstracting out atomic accesses when they are not required
(even on hosts that support compiler intrinsics for atomic
operations.)
</p>
<p>
In addition, there are two macros
</p>
<p>
<code>
_GLIBCXX_READ_MEM_BARRIER
</code>
</p>
<p>
<code>
GLIBCXX_WRITE_MEM_BARRIER
</code>
</p>
<p>
Which expand to the appropriate write and read barrier required by the
host hardware and operating system.
</p>
<h3 class="left">
<a name="pthread_api">Pthread Interface</a>
</h3>
<p>A thin layer above IEEE 1003.1 (ie pthreads) is used to abastract
the thread interface for GCC. This layer is called "gthread," and is
comprised of one header file that wraps the host's default thread layer with
a POSIX-like interfaces.
</p>
<p> The file &lt;gthr-default.h&gt; points to the deduced wrapper for
the current host. In libstdc++ implementation files,
&lt;bits/gthr.h&gt; is used to select the proper gthreads file.
</p>
<p>Within libstdc++ sources, all calls to underlying thread functionality
use this layer. More detail as to the specific interface can be found in the source <a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/gthr_8h-source.html">documentation</a>.
</p>
<p>By design, the gthread layer is interoperable with the types,
functions, and usage found in the usual &lt;pthread.h&gt; file,
including <code>pthread_t</code>, <code>pthread_once_t</code>, <code>pthread_create</code>,
etc.
</p>
<h3 class="left">
<a name="concur_api">Concurrence Interface</a>
</h3>
<p>The file &lt;ext/concurrence.h&gt; contains all the higher-level
constructs for playing with threads. In contrast to the atomics layer,
the concurrence layer consists largely of types. All types are defined within <code>namespace __gnu_cxx</code>.
</p>
<p>
These types can be used in a portable manner, regardless of the
specific environment. They are carefully designed to provide optimum
efficiency and speed, abstracting out underlying thread calls and
accesses when compiling for single-threaded situations (even on hosts
that support multiple threads.)
</p>
<p>The enumerated type <code>_Lock_policy</code> details the set of
available locking
policies: <code>_S_single</code>, <code>_S_mutex</code>,
and <code>_S_atomic</code>.
</p>
<ul>
<li><code>_S_single</code>
<p>Indicates single-threaded code that does not need locking.
</p>
</li>
<li><code>_S_mutex</code>
<p>Indicates multi-threaded code using thread-layer abstractions.
</p>
</li>
<li><code>_S_atomic</code>
<p>Indicates multi-threaded code using atomic operations.
</p>
</li>
</ul>
<p>The compile-time constant <code>__default_lock_policy</code> is set
to one of the three values above, depending on characteristics of the
host environment and the current compilation flags.
</p>
<p>Two more datatypes make up the rest of the
interface: <code>__mutex</code>, and <code>__scoped_lock</code>.
</p>
<p>
</p>
<p>The scoped lock idiom is well-discussed within the C++
community. This version takes a <code>__mutex</code> reference, and
locks it during construction of <code>__scoped_locke</code> and
unlocks it during destruction. This is an efficient way of locking
critical sections, while retaining exception-safety.
</p>
<p>Typical usage of the last two constructs is demonstrated as follows:
</p>
<pre>
#include &lt;ext/concurrence.h&gt;
namespace
{
__gnu_cxx::__mutex safe_base_mutex;
} // anonymous namespace
namespace other
{
void
foo()
{
__gnu_cxx::__scoped_lock sentry(safe_base_mutex);
for (int i = 0; i < max; ++i)
{
_Safe_iterator_base* __old = __iter;
__iter = __iter->_M_next;
__old->_M_detach_single();
}
}
</pre>
<p>In this sample code, an anonymous namespace is used to keep
the <code>__mutex</code> private to the compilation unit,
and <code>__scoped_lock</code> is used to guard access to the critical
section within the for loop, locking the mutex on creation and freeing
the mutex as control moves out of this block.
</p>
<p>Several exception classes are used to keep track of
concurrence-related errors. These classes
are: <code>__concurrence_lock_error</code>, <code>__concurrence_unlock_error</code>, <code>__concurrence_wait_error</code>,
and <code>__concurrence_broadcast_error</code>.
</p>
<h3 class="left">
<a name="atomic_impl">Details on builtin atomic support and library fallbacks</a>
</h3>
<p>The functions for atomic operations described above are either
implemented via compiler intrinsics (if the underlying host is
capable) or by library fallbacks.</p>
<p>Compiler intrinsics (builtins) are always preferred. However, as
the compiler builtins for atomics are not universally implemented,
using them directly is problematic, and can result in undefined
function calls. (An example of an undefined symbol from the use
of <code>__sync_fetch_and_add</code> on an unsupported host is a
missing reference to <code>__sync_fetch_and_add_4</code>.)
</p>
<p>In addition, on some hosts the compiler intrinsics are enabled
conditionally, via the <code>-march</code> command line flag. This makes
usage vary depending on the target hardware and the flags used during
compile.
</p>
<p> If builtins are possible, <code>_GLIBCXX_ATOMIC_BUILTINS</code>
will be defined.
</p>
<p>For the following hosts, intrinsics are enabled by default.
</p>
<ul>
<li>alpha</li>
<li>ia64</li>
<li>powerpc</li>
<li>s390</li>
</ul>
<p>For others, some form of <code>-march</code> may work. On
non-ancient x86 hardware, <code>-march=native</code> usually does the
trick.</p>
<p> For hosts without compiler intrinsics, but with capable
hardware, hand-crafted assembly is selected. This is the case for the following hosts:
</p>
<ul>
<li>cris</li>
<li>hppa</li>
<li>i386</li>
<li>i486</li>
<li>m48k</li>
<li>mips</li>
<li>sparc</li>
</ul>
<p>And for the rest, a simulated atomic lock via pthreads.
</p>
<p> Detailed information about compiler intrinsics for atomic operations can be found in the GCC <a href="http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html"> documentation</a>.
</p>
<p> More details on the library fallbacks from the porting <a href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/porting.html#Thread%20safety">section</a>.
</p>
</body>
</html>
libstdc++-v3/docs/html/ext/howto.html
......@@ -74,18 +74,13 @@
are deprecated but available as backwards-compatible extensions,
as discussed further below. <code>&lt;rope&gt;</code> is the
SGI specialization for large strings (&quot;rope,&quot;
&quot;large strings,&quot; get it? love those SGI folks).
&quot;large strings,&quot; get it? Love that geeky humor.)
<code>&lt;slist&gt;</code> is a singly-linked list, for when the
doubly-linked <code>list&lt;&gt;</code> is too much space
overhead, and <code>&lt;rb_tree&gt;</code> exposes the red-black
tree classes used in the implementation of the standard maps and
sets.
</p>
<p>Okay, about those hashing classes... these classes have been
deprecated by the unordered_set, unordered_multiset, unordered_map,
unordered_multimap containers in TR1 and the upcoming C++0x, and
may be removed in future releases.
</p>
<p>Each of the associative containers map, multimap, set, and multiset
have a counterpart which uses a
<a href="http://www.sgi.com/tech/stl/HashFunction.html">hashing
......@@ -111,11 +106,13 @@
components, and if you aren't scared about the possibility of
pathological cases, you'll probably get better performance from
hash_map.</em></blockquote>
<p>(Side note: for those of you wondering, <strong>&quot;Why wasn't a hash
table included in the Standard in the first #!$@ place?&quot;</strong>
I'll give a quick answer: it was proposed, but too late and in too
unorganized a fashion.)
<p>Okay, about the SGI hashing classes... these classes have been
deprecated by the unordered_set, unordered_multiset, unordered_map,
unordered_multimap containers in TR1 and the upcoming C++0x, and
may be removed in future releases.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
......
libstdc++-v3/docs/html/ext/sgiexts.html
......@@ -9,7 +9,7 @@
<meta name="KEYWORDS" content="libstdc++, libstdc++, GCC, g++, STL, SGI" />
<meta name="DESCRIPTION" content="SGI extensions preserved in libstdc++." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>SGI extensions to the library in libstdc++</title>
<title>HP/SGI STL extensions</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
......@@ -19,29 +19,29 @@
</head>
<body>
<h1 class="centered"><a name="top">SGI extensions to the library in
libstdc++</a></h1>
<h1 class="centered"><a name="top">HP/SGI STL extensions</a></h1>
<p>This page describes the extensions that SGI made to their version of the
STL subset of the Standard C++ Library. For a time we
<a href="../faq/index.html#5_3">tracked and imported changes and updates
from most of the SGI STL</a>, up through their (apparently) final release.
Their extensions were mostly preserved.
<p>This page describes the extensions that SGI made to the STL subset
of the Standard C++ Library, which also includes work from the
originating HP codebase. This work is the basis for much of
libstdc++, and where possible these extensions have been
preserved.
</p>
<p>They are listed according to the chapters of the library that they
extend (see <a href="../documentation.html#3">the chapter-specific notes</a>
for a description). Not every chapter may have extensions, and the
extensions may come and go. Also, this page is incomplete because the
author is pressed for time. Check back often; the latest change was on
$Date: 2003/04/16 17:02:47 $ (UTC).
<p>What follows is a listing of these extensions, according to the
chapters of the library that they extend
(see <a href="../documentation.html#3">the chapter-specific
notes</a> for a description). Not every chapter has extensions,
and existing extensions may be removed (or moved) as their
functionality is standardized.
</p>
<p>Descriptions range from the scanty to the verbose. You should also check
the <a href="../documentation.html#4">generated documentation</a> for notes
and comments, especially for entries marked with '*'. For more complete
doumentation, see the SGI website. For <em>really</em> complete
documentation, buy a copy of Matt Austern's book. *grin*
<p>Descriptions range from the scanty to the verbose. Also check
the <a href="../documentation.html#4">generated documentation</a>
for notes and comments, especially for entries marked with '*'.
For more complete doumentation, see the SGI website.
For <em>really</em> complete documentation, consider perusing a
copy of Matt Austern's book "Generic Programming and the STL."
</p>
<p>Back to the <a href="howto.html">libstdc++ extensions</a>.
......
libstdc++-v3/docs/html/faq/index.html
......@@ -1052,14 +1052,26 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
<hr />
<h2><a name="5_6">5.6 Is libstdc++ thread-safe?</a></h2>
<p>libstdc++ strives to be thread-safe when all of the following
<p>The library strives to be thread-safe when all of the following
conditions are met:
</p>
<ul>
<li>The system's libc is itself thread-safe,</li>
<li><code>gcc -v</code> reports a thread model other than 'single',</li>
<li>[pre-3.3 only] a non-generic implementation of atomicity.h
exists for the architecture in question.</li>
<li>The compiler in use reports a thread model other than 'single'. This can be tested via output from <code>gcc -v</code>. Multi-thread capable versions of gcc output something like this:
<pre>
%gcc -v
Using built-in specs.
...
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
</pre>
<p>Look for "Thread model" lines that aren't equal to "single."</p>
</li>
<li>Requisite command-line flags are used for atomic operations and threading. Examples of this include <code>-pthread</code> and <code>-march=native</code>, although specifics vary depending on the host environment. See <a href="http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html">Machine Dependent Options</a>.</li>
<li>An implementation of atomicity.h functions
exists for the architecture in question. See the internals documentation for more <a href="../ext/concurrence.html">details</a>.</li>
</ul>
<p>The user-code must guard against concurrent method calls which may
access any particular library object's state. Typically, the
......
libstdc++-v3/include/precompiled/stdc++.h
// C++ includes used for precompiling -*- C++ -*-
// Copyright (C) 2003 Free Software Foundation, Inc.
// Copyright (C) 2003, 2007 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
......@@ -51,6 +51,17 @@
#include <cstring>
#include <ctime>
#ifdef __GXX_EXPERIMENTAL_CXX0X__
#include <ccomplex>
#include <cfenv>
#include <cinttypes>
#include <cstdbool>
#include <cstdint>
#include <ctgmath>
#include <cwchar>
#include <cwctype>
#endif
// C++
#include <algorithm>
#include <bitset>
......@@ -84,3 +95,14 @@
#include <utility>
#include <valarray>
#include <vector>
#ifdef __GXX_EXPERIMENTAL_CXX0X__
#include <array>
#include <random>
#include <regex>
#include <system_error>
#include <tuple>
#include <type_traits>
#include <unordered_map>
#include <unordered_set>
#endif
libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc
......@@ -121,6 +121,7 @@
#include <stdexcept>
#include <streambuf>
#include <string>
#include <system_error>
#include <tuple>
#include <typeinfo>
#include <type_traits>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment