diff options
author | upstream source tree <ports@midipix.org> | 2015-03-15 20:14:05 -0400 |
---|---|---|
committer | upstream source tree <ports@midipix.org> | 2015-03-15 20:14:05 -0400 |
commit | 554fd8c5195424bdbcabf5de30fdc183aba391bd (patch) | |
tree | 976dc5ab7fddf506dadce60ae936f43f58787092 /libstdc++-v3/doc/html/manual/ext_concurrency.html | |
download | cbb-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.html | 91 |
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=" ISO C++ , library "/><meta name="keywords" content=" ISO C++ , library "/><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 <ext/concurrence.h> 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 +<ext/atomicity.h>, 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> |