summaryrefslogtreecommitdiff
path: root/libstdc++-v3/doc/html/manual/ext_concurrency.html
diff options
context:
space:
mode:
authorupstream source tree <ports@midipix.org>2015-03-15 20:14:05 -0400
committerupstream source tree <ports@midipix.org>2015-03-15 20:14:05 -0400
commit554fd8c5195424bdbcabf5de30fdc183aba391bd (patch)
tree976dc5ab7fddf506dadce60ae936f43f58787092 /libstdc++-v3/doc/html/manual/ext_concurrency.html
downloadcbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.bz2
cbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.xz
obtained gcc-4.6.4.tar.bz2 from upstream website;upstream
verified gcc-4.6.4.tar.bz2.sig; imported gcc-4.6.4 source tree from verified upstream tarball. downloading a git-generated archive based on the 'upstream' tag should provide you with a source tree that is binary identical to the one extracted from the above tarball. if you have obtained the source via the command 'git clone', however, do note that line-endings of files in your working directory might differ from line-endings of the respective files in the upstream repository.
Diffstat (limited to 'libstdc++-v3/doc/html/manual/ext_concurrency.html')
-rw-r--r--libstdc++-v3/doc/html/manual/ext_concurrency.html91
1 files changed, 91 insertions, 0 deletions
diff --git a/libstdc++-v3/doc/html/manual/ext_concurrency.html b/libstdc++-v3/doc/html/manual/ext_concurrency.html
new file mode 100644
index 000000000..99718e04f
--- /dev/null
+++ b/libstdc++-v3/doc/html/manual/ext_concurrency.html
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Chapter 28. Concurrency</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.76.1"/><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; "/><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; "/><link rel="home" href="../spine.html" title="The GNU C++ Library"/><link rel="up" href="extensions.html" title="Part III.  Extensions"/><link rel="prev" href="ext_demangling.html" title="Chapter 27. Demangling"/><link rel="next" href="bk01pt03ch28s02.html" title="Implementation"/></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 28. Concurrency</th></tr><tr><td align="left"><a accesskey="p" href="ext_demangling.html">Prev</a> </td><th width="60%" align="center">Part III. 
+ Extensions
+
+</th><td align="right"> <a accesskey="n" href="bk01pt03ch28s02.html">Next</a></td></tr></table><hr/></div><div class="chapter" title="Chapter 28. Concurrency"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.concurrency"/>Chapter 28. Concurrency</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="ext_concurrency.html#manual.ext.concurrency.design">Design</a></span></dt><dd><dl><dt><span class="section"><a href="ext_concurrency.html#manual.ext.concurrency.design.threads">Interface to Locks and Mutexes</a></span></dt><dt><span class="section"><a href="ext_concurrency.html#manual.ext.concurrency.design.atomics">Interface to Atomic Functions</a></span></dt></dl></dd><dt><span class="section"><a href="bk01pt03ch28s02.html">Implementation</a></span></dt><dd><dl><dt><span class="section"><a href="bk01pt03ch28s02.html#manual.ext.concurrency.impl.atomic_fallbacks">Using Builtin Atomic Functions</a></span></dt><dt><span class="section"><a href="bk01pt03ch28s02.html#manual.ext.concurrency.impl.thread">Thread Abstraction</a></span></dt></dl></dd><dt><span class="section"><a href="bk01pt03ch28s03.html">Use</a></span></dt></dl></div><div class="section" title="Design"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.concurrency.design"/>Design</h2></div></div></div><div class="section" title="Interface to Locks and Mutexes"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.design.threads"/>Interface to Locks and Mutexes</h3></div></div></div><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 class="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 class="code">_Lock_policy</code> details the set of
+available locking
+policies: <code class="code">_S_single</code>, <code class="code">_S_mutex</code>,
+and <code class="code">_S_atomic</code>.
+</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p><code class="code">_S_single</code></p><p>Indicates single-threaded code that does not need locking.
+</p></li><li class="listitem"><p><code class="code">_S_mutex</code></p><p>Indicates multi-threaded code using thread-layer abstractions.
+</p></li><li class="listitem"><p><code class="code">_S_atomic</code></p><p>Indicates multi-threaded code using atomic operations.
+</p></li></ul></div><p>The compile-time constant <code class="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 class="code">__mutex</code>, and <code class="code">__scoped_lock</code>.
+</p><p>
+</p><p>The scoped lock idiom is well-discussed within the C++
+community. This version takes a <code class="code">__mutex</code> reference, and
+locks it during construction of <code class="code">__scoped_locke</code> and
+unlocks it during destruction. This is an efficient way of locking
+critical sections, while retaining exception-safety.
+</p></div><div class="section" title="Interface to Atomic Functions"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.design.atomics"/>Interface to Atomic Functions</h3></div></div></div><p>
+Two functions and one type form the base of atomic support.
+</p><p>The type <code class="code">_Atomic_word</code> is a signed integral type
+supporting atomic operations.
+</p><p>
+The two functions functions are:
+</p><pre class="programlisting">
+_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 class="code">namespace __gnu_cxx</code>.
+</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>
+<code class="code">
+__exchange_and_add_dispatch
+</code>
+</p><p>Adds the second argument's value to the first argument. Returns the old value.
+</p></li><li class="listitem"><p>
+<code class="code">
+__atomic_add_dispatch
+</code>
+</p><p>Adds the second argument's value to the first argument. Has no return value.
+</p></li></ul></div><p>
+These functions forward to one of several specialized helper
+functions, depending on the circumstances. For instance,
+</p><p>
+<code class="code">
+__exchange_and_add_dispatch
+</code>
+</p><p>
+Calls through to either of:
+</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p><code class="code">__exchange_and_add</code>
+</p><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 class="listitem"><p><code class="code">__exchange_and_add_single</code>
+</p><p>Single threaded version. Inlined.</p></li></ul></div><p>However, only <code class="code">__exchange_and_add_dispatch</code>
+and <code class="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 class="code">
+_GLIBCXX_READ_MEM_BARRIER
+</code>
+</p><p>
+<code class="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></div></div></div><div class="navfooter"><hr/><table width="100%" summary="Navigation footer"><tr><td align="left"><a accesskey="p" href="ext_demangling.html">Prev</a> </td><td align="center"><a accesskey="u" href="extensions.html">Up</a></td><td align="right"> <a accesskey="n" href="bk01pt03ch28s02.html">Next</a></td></tr><tr><td align="left" valign="top">Chapter 27. Demangling </td><td align="center"><a accesskey="h" href="../spine.html">Home</a></td><td align="right" valign="top"> Implementation</td></tr></table></div></body></html>