From 554fd8c5195424bdbcabf5de30fdc183aba391bd Mon Sep 17 00:00:00 2001 From: upstream source tree Date: Sun, 15 Mar 2015 20:14:05 -0400 Subject: obtained gcc-4.6.4.tar.bz2 from upstream website; 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. --- libstdc++-v3/doc/html/manual/ext_concurrency.html | 91 +++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 libstdc++-v3/doc/html/manual/ext_concurrency.html (limited to 'libstdc++-v3/doc/html/manual/ext_concurrency.html') 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 @@ + + +Chapter 28. Concurrency
Chapter 28. Concurrency
Prev Part III.  + Extensions + + Next

Chapter 28. Concurrency

Table of Contents

Design
Interface to Locks and Mutexes
Interface to Atomic Functions
Implementation
Using Builtin Atomic Functions
Thread Abstraction
Use

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 namespace __gnu_cxx. +

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

The enumerated type _Lock_policy details the set of +available locking +policies: _S_single, _S_mutex, +and _S_atomic. +

The compile-time constant __default_lock_policy is set +to one of the three values above, depending on characteristics of the +host environment and the current compilation flags. +

Two more datatypes make up the rest of the +interface: __mutex, and __scoped_lock. +

+

The scoped lock idiom is well-discussed within the C++ +community. This version takes a __mutex reference, and +locks it during construction of __scoped_locke and +unlocks it during destruction. This is an efficient way of locking +critical sections, while retaining exception-safety. +

+Two functions and one type form the base of atomic support. +

The type _Atomic_word is a signed integral type +supporting atomic operations. +

+The two functions functions are: +

+_Atomic_word
+__exchange_and_add_dispatch(volatile _Atomic_word*, int);
+
+void
+__atomic_add_dispatch(volatile _Atomic_word*, int);
+

Both of these functions are declared in the header file +<ext/atomicity.h>, and are in namespace __gnu_cxx. +

+These functions forward to one of several specialized helper +functions, depending on the circumstances. For instance, +

+ +__exchange_and_add_dispatch + +

+Calls through to either of: +

However, only __exchange_and_add_dispatch +and __atomic_add_dispatch 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.) +

+In addition, there are two macros +

+ +_GLIBCXX_READ_MEM_BARRIER + +

+ +_GLIBCXX_WRITE_MEM_BARRIER + +

+Which expand to the appropriate write and read barrier required by the +host hardware and operating system. +

Prev Up Next
Chapter 27. Demangling Home Implementation
-- cgit v1.2.3