C++并发实战-第五章-总学习笔记第3
[TOC]
C++ 并发实战《C++ Concurrency in Action》的学习笔记 3, 记录第五章的部分 The C++ memory model and operations on atomic types.
内容是 C++ 内存模型与原子类型及其操作等中层的技术.
Chapter 5 The C++ memory model and operations on atomic types
5.1 Memory model basics
memory model: the basic structural aspects, which relate to how things are laid out in memory, and the concurrency aspects.
5.1.1 Objects and memory locations
The C++ Standard defines an object as a region of storage, although it goes on to assign properties to these objects, such as their type and lifetime. 也存在 sub-objects.
存储单位: an object is stored in one or more memory locations.
下图是一个显示 object 与 memory location 之间关系的示意图:
bf3 大小为 0, 不占据 memory location, 甚至不应该有自己的名字(那一行应该删除, 否则不通过编译): Note how the zero-length bit field bf3 (the name is commented out because zero-length bit fields must be unnamed) separates bf4 into its own memory location, but doesn’t have a memory location itself.
总结为 4 个方面:
- Every variable is an object, including those that are members of other objects.
- Every object occupies at least one memory location.
- Variables of fundamental types such as int or char occupy exactly one memory location, whatever their size, even if they’re adjacent or part of an array.
- Adjacent bit fields are part of the same memory location.
5.1.2 Objects, memory locations, and concurrency
race condition 发生的内存微观基础: 多个线程修改同一个 memory location.
解决办法: 确定 some defined ordering(修改顺序): mutex or atomic operations.
5.1.3 Modification orders
要么 programmer 确定 Modification orders, 要么通过 atomic operations 让 compiler 确定.(If you do use atomic operations, the compiler is responsible for ensuring that the necessary synchronization is in place.
)
注意:
Although all threads must agree on the modification orders of each individual object in a program, they don’t necessarily have to agree on the relative order of operations on separate objects.
5.2 Atomic operations and types in C++
定义: An atomic operation is an indivisible operation. You can’t observe such an operation half-done from any thread in the system; it’s either done or not done.
5.2.1 The standard atomic types
实现 automic 的 2 种方式:
- 直接的: operations on a given type are done directly with atomic instructions (
x.is_lock_free()returnstrue) - 间接的: done by using a lock internal to the compiler and library (
x.is_lock_free()returnsfalse). => 这种情况下有可能还不如自己在外面用 mutex 来的划算.
C++17 static constexpr member variable, X::is_always_lock_free, which is true if and only if the atomic type X is lock-free for all
supported hardware.
标准也提供了宏方便进行 portable 开发:
ATOMIC_BOOL_LOCK_FREE, ATOMIC_CHAR_LOCK_FREE, ATOMIC_CHAR16_T_LOCK_FREE, ATOMIC_CHAR32_T_LOCK_FREE, ATOMIC_WCHAR_T_LOCK_FREE, ATOMIC_SHORT_LOCK_FREE, ATOMIC_INT_LOCK_FREE, ATOMIC_LONG_LOCK_FREE, ATOMIC_LLONG_LOCK_FREE, and ATOMIC_POINTER_LOCK_FREE.
value 0: if the atomic type is never lock-free.
value 2: if the atomic type is always lock-free.
value 1: if the lock-free status of the corresponding atomic type is a runtime property.
only type that doesn’t provide an is_lock_free() member function is std::atomic_flag. 可以在其基础上开发简单的锁: once you have a simple lock-free Boolean flag, you can use that to implement a simple lock and implement all the other atomic types using that as a basis.
简单的意思是 objects of the std::atomic_flag type are initialized to clear, and they can then either be queried and set (with the test_and_set() member function) or cleared (with the clear() member function). That’s it: no assignment, no copy construction, no test and clear, no other operations at all.
标准规定的 basic atomic types 一览表
a set of typedefs for the atomic types corresponding to the various non-atomic Standard Library typedefs such as std::size_t.
alias 命名规则: standard typedef T, the corresponding atomic type is the same name with an atomic_ prefix: atomic_T. The same applies to the built-in types, except that signed is abbreviated as s, unsigned as u, and long long as llong.
原子类型特点:
not copyable or assignable in the conventional sense, 但是支持通过成员函数实现:
load()andstore()member functions,exchange(),compare_exchange_weak(), andcompare_exchange_strong().支持 operator:
+=,-=,*=,|=, and so on. the integral types andstd::atomic<>specializations for++and--pointers support.返回值 The return value from the assignment operators and member functions is either the value stored (in the case of the assignment operators) or the value prior to the operation (in the case of the named functions).
user-defined type: the operations are limited to
load(),store()(and assignment from and conversion to the user-defined type),exchange(),compare_exchange_weak(), andcompare_exchange_strong().optional memory-ordering argument: the default ordering is used, which is the strongest ordering:
std::memory_order_seq_cst. operations are divided into three categories:- Store operations, which can have
memory_order_relaxed,memory_order_release, ormemory_order_seq_cst ordering. - Load operations, which can have
memory_order_relaxed,memory_order_consume,memory_order_acquire, ormemory_order_seq_cst ordering. - Read-modify-write operations, which can have
memory_order_relaxed,memory_order_consume,memory_order_acquire,memory_order_release,memory_order_acq_rel, ormemory_order_seq_cstordering.
- Store operations, which can have
5.2.2 Operations on std::atomic_flag
特点
one of two states: set or clear.
It’s also the only type guaranteed to be lock-free.
must be initialized with
ATOMIC_FLAG_INIT(a clear state).
1 | std::atomic_flag f=ATOMIC_FLAG_INIT; |
If the
std::atomic_flagobject has static storage duration, it’s guaranteed to be statically initialized, which means that there are no
initialization-order issues; it will always be initialized by the time of the first operation on the flag.only three things you can do with it: destroy it, clear it, or set it and query the previous value.
Both the
clear()(a store operation) andtest_and_set()(read-modify-write operation) member functions can have a memory order specified.
C++ 20 的接口如下:
1 | namespace std { |
A single operation on two distinct objects can’t be atomic.
应用: 自旋锁
1 | class spinlock_mutex |
特点: it’s a poor choice if you expect there to be any degree of contention, but it’s enough to ensure mutual exclusion.
5.2.3 Operations on std::atomic<bool>
the assignment operators they support return values (of the corresponding non-atomic type) rather than references.
这样就不用对所有依赖于赋值后的引用进行 additional load 操作, 不过 C++ 20 里增加了 std::atomic<ref> 增加对引用类型的原子性操作.
支持操作: store() is a store operation, whereas load() is a load operation. exchange() is a read-modify-write operation.
隐式转换: supports a plain nonmodifying query of the value with an implicit conversion to plain bool or with an explicit call to load().
std::atomic<bool> may not be lock-free.
STORING A NEW VALUE (OR NOT) DEPENDING ON THE CURRENT VALUE
compare-exchange: compare_exchange_weak() and compare_exchange_strong() member functions. 机理: compares the value of the atomic variable with a supplied expected value and stores the supplied desired value if they’re equal. If the values aren’t equal, the expected value is updated with the value of the atomic variable.
区别:
compare_exchange_weak(): the store might not be successful even if the original value was equal to the expected value, in which case the value of the variable is unchanged and the return value of compare_exchange_weak() is false.
原因: This is most likely to happen on machines that lack a single compare-and-exchange instruction, if the processor can’t guarantee that the operation has been done atomically—possibly because the thread performing the operation was switched out in the middle of the necessary sequence of instructions and another thread scheduled in its place by the operating system where there are more threads than processors. This is called a spurious failure. 应对假失败, 使用 loop:
1 | bool expected=false; |
compare_exchange_strong() is guaranteed to return false only if the value wasn’t equal to the expected value. This can eliminate the need for
loops.
区别使用: If the calculation of the value to be stored is simple, it may be beneficial to use compare_exchange_weak() in order to avoid a double loop on platforms where compare_exchange_weak() can fail spuriously (and so compare_exchange_strong() contains a loop). On the other hand, if the calculation of the value to be stored is time-consuming, it may make sense to use compare_exchange_strong() to avoid having to recalculate the value to store when the expected value hasn’t changed(因为 && 是短接的, 前者失败不会触发 time-consuming 的后者, 只有前者报 true 才会进行后者).
memory-ordering semantics rules:
- differ in the case of success and failure.
- A failed compare-exchange doesn’t do a store, so it can’t have
memory_order_releaseormemory_order_acq_relsemantics. - can’t supply stricter memory ordering for failure than for success.
- If you don’t specify an ordering for failure, it’s assumed to be the same as that for success, except that the release part of the ordering is stripped.
- If you specify neither, they default to
memory_order_seq_cstas usual.
5.2.4 Operations on std::atomic<T*>: pointer arithmetic
C++ 20 的接口如下:
1 | namespace std { |
pointer arithmetic operations, provided by the fetch_add() and fetch_sub() member functions and the += and -= operators, ++ and --.
exchange-and-add: return the original value (so x.fetch_add(3) will update x to point to the fourth value but return a pointer to the first value in the array. it’s an atomic read-modify-write operation. the return value is a plain T* value rather than a reference to the std::atomic<T*> object.
5.2.5 Operations on standard atomic integral types
C++ 20 的接口如下:
1 | namespace std { |
atomic integral values are typically used either as counters or as bitmasks.
5.2.6 The std::atomic<> primary class template
std::atomic<UDT> for some user-defined type UDT 的要求: must have a trivial copy-assignment operator.
- must not have any virtual functions or
- virtual base classes and
- must use the compiler-generated copy-assignment operator.
- every base class and non-static data member of a user-defined type must also have a trivial copy-assignment operator.
- This permits the compiler to use
memcpy()or an equivalent operation for assignment operations, because there’s no user-written code to run. - compare-exchange operations do bitwise comparison as if using
memcmp, rather than using any comparison operator that may be defined for UDT. 注意 padding bits 的存在.
为什么要这么要求?
- In general, the compiler isn’t going to be able to generate lock-free code for
std::atomic<UDT>, so it will have to use an internal lock for all the operations. If user-supplied copy-assignment or comparison operators were permitted, this would require passing a reference to the protected data as an argument to a user-supplied function, violating the guideline(不要随意使用指针/引用作为 shared data 的接口). - Also, the library is entirely at liberty to use a single lock for all atomic operations that need it, and allowing user-supplied functions to be called while holding that lock might cause deadlock or cause other threads to block because a comparison operation took a long time.
- Finally, these restrictions increase the chance that the compiler will be able to make use of atomic instructions directly for
std::atomic<UDT>(and make a particular instantiation lock-free), because it can treat the user-defined type as a set of raw bytes.
C++ 20 之前不支持 std::atomic<floating-point_types>, 原因是: The operation(compare_exchange_strong) may fail even though the old stored value was equal in value to the comparand, if the stored value had a different representation.
虽然 C++ 20 支持了浮点数, 但是参考意义还是存在的, You’ll get similar behavior with compare_exchange_strong if you use std::atomic<> with a user-
defined type that has an equality-comparison operator defined, and that operator differs from the comparison using memcmp—the operation may fail because the otherwise-equal values have a different representation.
double-word-compare-and-swap (DWCAS) instruction: Platforms use atomic instructions for user-defined types that are twice the size of an int or void*.
小一些的类型: If your UDT is the same size as (or smaller than) an int or a void*, most common platforms will be able to use atomic instructions for std::atomic<UDT>.
对于容器: 虽然不能直接实例化容器对象, 但是可以实例化含有指针的容器. you can’t create std::atomic<std::vector<int>>, but you can instantiate std::atomic<> with classes containing counters or flags or pointers or even arrays of simple data elements.
Table 5.3 The operations available on atomic types
5.2.7 Free functions for atomic operations
All the free functions take a pointer to the atomic object as the first parameter. 例子 the equivalent of a.load(std::memory_order_acquire) isstd::atomic_load_explicit(&a, std::memory_order_acquire)(specify the memory ordering again have the _explicit suffix), 只有 std::atomic_flag 比较特殊: std::atomic_flag_test_and_set().
The free functions are designed to be C-compatible, so they use pointers rather than references in all cases.
对智能指针的支持: The atomic operations available are load, store, exchange, and compare-exchange, which are provided as overloads of the same operations on the standard atomic types, taking an std::shared_ptr<>* as the first argument. 例子如下:
1 | std::shared_ptr<my_data> p; |
The Concurrency TS 也提供了 std::experimental::atomic_shared_ptr<T> 更推荐使用这个. Even if it is not lock-free(但还是有可能是的), std::experimental::atomic_shared_ptr is to be recommended over using the atomic free functions on a plain std::shared_ptr. 原因是 clearer in your code.
5.3 Synchronizing operations and enforcing ordering
happens-before and synchronizes-with
happens-before is transitive.
1 |
|
5.3.1 The synchronizes-with relationship
The synchronizes-with relationship is something that you can get only between operations on atomic types.
机制: a suitably-tagged atomic write operation, W,
on a variable, x,
synchronizes with
a suitably-tagged atomic read operation on x that reads the value
stored by either that write, W,
or a subsequent atomic write operation on x by the same thread that performed the initial write, W,
or a sequence of atomic read-modify-write operations on x (such as fetch_add() or compare_exchange_weak()) by any thread,
where the value read by the first thread in the sequence is the value written by W.
直观地说: if thread A stores a value and thread B reads that value, there’s a synchronizes-with relationship between the store in thread A and the load in thread B.
5.3.2 The happens-before relationship
没有顺序的一种情况: If the operations occur in the same statement, in general there’s no happens-before relationship between them, because they’re unordered.(当然也有一个 statement 中顺序执行的情况, 例如 built-in comma operator 分隔, 前后相互依赖等)
线程间的顺序: if operation A in one thread synchronizes with operation B in another thread, then A inter-thread happens before B. It’s also a transitive relation. 应用: if you make a series of changes to data in a single thread, you need only one synchronizes-with relationship for the data to be visible to subsequent operations on the thread that executed C.
strongly-happens-before relationship 不同之处: operations tagged with memory_order_consume(此模式下无法实现 strong) participate in inter-thread-happens-before relationships (and thus happens-before relationships), but not in strongly-happens-before relationships.
5.3.3 Memory ordering for atomic operations
represent three models:
- sequentially consistent ordering (
memory_order_seq_cst), - acquire-release ordering (
memory_order_consume,memory_order_acquire,memory_order_release, andmemory_order_acq_rel), and - relaxed ordering (
memory_order_relaxed).
区别: These distinct memory-ordering models can have varying costs on different CPU architectures.
细分的作用: allows experts to take advantage of the increased performance of the more fine-grained ordering relationships.
happens-before 与 synchronizes-with 的解读可以参考链接.
SEQUENTIALLY CONSISTENT ORDERING
It implies that the behavior of the program is consistent with a simple sequential view of the world.
All threads must see the same order of operations.
对现实的指导意义: You can write down all the possible sequences of operations by different threads, eliminate those that are inconsistent, and verify that your code behaves as expected in the others.
注意, 对 atomic operation 的设定不具备传递性, 此处设定了, 接下来的别处还需要再设定. This constraint doesn’t carry forward to threads that use atomic operations with relaxed memory orderings; they can still see the operations in a different order, so you must use sequentially consistent operations on all your threads. 有些顺序的限制(依赖关系)是可以 carry forward 的.
缺点: 在 a weakly-ordered machine with many processors 的情况下, 代价会非常高. 需不需要使用需要我们自己查阅 documentation for your target processor architectures.
例子代码(在原书的基础上增加打印):
1 |
|
assert(z.load()!=0); 永远不会 true. 执行过程如下:
一些可能的执行顺序(x86_64, gcc 5.4.0, 未加优化):
1 | Thread 1: x store |
此处需要注意的是打印的结果只能做为大致的参考, 因为打印命令时间可能是被延迟的, 例如最后一个输出结果.
整个过程我是这么思考的, 因为加了 Sequential consistency 选项, 形成一个 a single total order: 两个线程看到的都是无论对于 x, 还是 y, 都是状态一致的. 例如, x 先被 store 为 true y 没有被 store, read_x_then_y 可以跳出 while 但是由于 y 是 false 所以 ++z 不能实现就结束了. 与此同时在另一个线程 read_y_then_x 里, 也是如此的顺序, 先是 x == true 且 y == false 因此卡在 while 上, 但当 y store 成 true 跳出 while 后, x 保证还是 true 而不是混乱地有可能取得 x 的值是初始的 false 因此能顺利地 ++z. 不管 x 与 y 谁先 store 成 true 总可以有一个线程导致 ++z, 当然也有可能都会 ++z.
总结: Sequential consistency is the most straightforward and intuitive ordering, but it’s also the most expensive memory ordering.
NON-SEQUENTIALLY CONSISTENT MEMORY ORDERINGS
there’s no longer a single global order of events: different threads can see different views of the same operations.
threads don’t have to agree on the order of events.
原因是: It’s not just that the compiler can reorder the instructions. Even if the threads are running the same bit of code, they can disagree on the order of events because of operations in other threads in the absence of explicit ordering constraints, because the different CPU caches and internal buffers can hold different values for the same memory.
In the absence of other ordering constraints, the only requirement is that all threads agree on the modification order of each individual variable.
RELAXED ORDERING
Operations on the same variable within a single thread still obey happens-before relationships, but there’s almost no requirement on ordering relative to other threads. 一个线程上有顺序, 线程间没有任何可以依赖的顺序.
The only requirement is that accesses to a single atomic variable from the same thread can’t be reordered; 例如: once a given thread has seen a particular value of an atomic variable, a subsequent read by that thread can’t retrieve an earlier value of the variable.
1 |
|
这个例子中在 write_x_then_y 函数中线程 a 可以保证执行顺序, 但在另一个线程 b 中看到的顺序则不一定, 因此有可能出现 y 为 true 的情况下, x 依旧未被 store 为 true 的情况, 因此 ++z 未能得到执行.
1 |
|
一种可能的输出是:
1 | (0,0,0),(1,0,0),(2,0,0),(3,0,0),(4,0,0),(5,7,0),(6,7,8),(7,9,8),(8,9,8),(9,9,10) |
反映出一些规律:
std::memory_order_relaxed模式下,x,y,z(还有var_to_inc)的执行顺序在单个线程里是确定的: 这可以在所有行的输出中的任意x,y,z之一的变量的递增顺序可以看出来.- 由于
var_to_inc的作用, 前三行increment的输出依次按照x,y,z的顺序分别从 0 递增到 9, 也是反映了上面的点. - 线程间除了自己线程上的操作是连续的, 看到其他线程上的值都是不连续的, 不同线程看到的结果也不一样. 例如第三行压根没有看到前两个线程的输出, 但后面两个
read_vals虽然看到了, 但看到的结果不一样. - 基本的时间规律还是被遵守的, 任何一行的输出不存在减小的情况, 最多不更新或者是跨越式更新.
- 只要是满足上面的规律, 其他的输出结果都是合法的.
UNDERSTANDING RELAXED ORDERING
本小节, 作者举出了一个非常贴切生动的例子说明 std::memory_order_relaxed 模式. 我直接粘贴在此处.
imagine that each variable is a man in a cubicle with a notepad. On his notepad is a list of values. You can phone him and ask him to give you
a value, or you can tell him to write down a new value. If you tell him to write down a new value, he writes it at the bottom of the list. If you ask him for a value, he reads you a number from the list.
The first time you talk to this man, if you ask him for a value, he may give you any value from the list he has on his pad at the time. If you then ask him for another value, he may give you the same one again or a value from farther down the list. He’ll never give you a value from farther up the list. If you tell him to write down a number and then subsequently ask him for a value, he’ll give you either the number you told him to write down or a number below that on the list.
Imagine for a moment that his list starts with the values 5, 10, 23, 3, 1, and 2. If you ask for a value, you could get any of those. If he gives you 10, then the next time you ask he could give you 10 again, or any of the later ones, but not 5. If you call him five times, he could say “10, 10, 1, 2, 2,” for example. If you tell him to write down 42, he’ll add it to the end of the list. If you ask him for a number again, he’ll keep telling you “42” until he has another number on his list and he feels like telling it to you. Now, imagine your friend Carl also has this man’s number. Carl can also phone him and either ask him to write down a number or ask for one, and he applies the same rules to Carl as he does to you. He has only one phone, so he can only deal with one of you at a time, so the list on his pad is a nice straightforward list. But just because you got him to write down a new number doesn’t mean he has to tell it to Carl, and vice versa. If Carl asked him for a number and was told “23,” then just because you asked the man to write down 42 doesn’t mean he’ll tell that to Carl next time. He may tell Carl any of the numbers 23, 3, 1, 2, 42, or even the 67 that Fred told him to write down after you called. He could very well tell Carl “23, 3, 3, 1, 67” without
being inconsistent with what he told you. It’s like he keeps track of which number he told to whom with a little moveable sticky note for each person, like in figure 5.5.
Now imagine that there’s not just one man in a cubicle but a whole cubicle farm, with loads of men with phones and notepads. These are all our atomic variables. Each variable has its own modification order (the list of values on the pad), but there’s no relationship between them at all. If each caller (you, Carl, Anne, Dave, and Fred) is a thread, then this is what you get when every operation uses memory_order_relaxed. There are a few additional things you can tell the man in the cubicle, such as “Write down this number, and tell me what was at the bottom of the list” (exchange) and “Write down this number if the number on the bottom of the list is that; otherwise tell me what I should have guessed” (compare_exchange_strong), but that doesn’t affect the general principle.
ACQUIRE-RELEASE ORDERING
成对使用: Synchronization is pairwise between the thread that does the release and the thread that does the acquire. A release operation synchronizes-with an acquire operation that reads the value written.
1 |
|
此例中 assert 也不会为真. 因为使用了 acquire-release semantics.
注意
read_y_then_x中 while loop 的作用, 如果没有的话,assert是有可能 fire 的.
作者对上面举出的 men with notepads in their cubicles 的例子中增加了 batch 的概念来解释 acquire-release semantics.
同时 acquire-release semantics 具有传递性, 因此可以形成一连串的多个线程间的同步关系: it’s transitive: if A inter-thread happens before B and B inter-thread happens before C, then A inter-thread happens before C.
TRANSITIVE SYNCHRONIZATION WITH ACQUIRE-RELEASE ORDERING
本小结作者提出了 sequence before 的概念, 可以简单地理解为单个线程上操作(statement)的顺序关系.
1 |
|
借助 acquire-release semantics 的传递性可以构建 chain: data store happens before sync1 store happens before sync1 load happens before sync2 store happens before sync2 load happens before data load.
可以把 sync1 与 sync2 组合在一起, 使用 option std::memory_order_acq_rel, 即先 acquire 再 release, 同时要使用 read-modify-write operation 来进行同步与判断, 改进后的程序如下:
1 | std::atomic<int> sync(0); |
其他的原子操作也可以与 acquire-release semantics 的其他 option 组合, 但有意义与否, 如何使用需要 programmer 仔细判断. 例子 A fetch_sub operation with memory_order_acquire semantics doesn’t synchronize with anything, even though it stores a value, because it isn’t a release operation.
acquire-release semantics 与其他 options 之间的组合:
- If you mix acquire-release operations with sequentially consistent operations,
- the sequentially consistent loads behave like loads with acquire semantics, and
- sequentially consistent stores behave like stores with release semantics.
- Sequentially consistent read-modify-write operations behave as both acquire and release operations.
- Relaxed operations are still relaxed but are bound by the additional synchronizes-with and consequent happens-before relationships introduced through the use of acquire-release semantics.
其实 mutex 本身也是 acquire-release semantics: locking a mutex is an acquire operation, and unlocking the mutex is a release operation.
使用 acquire-release semantics 的场景: if you use acquire and release orderings on atomic variables to build a simple lock, then from the point of view of code that uses the lock, the behavior will appear sequentially consistent, even though the internal operations are not(这部分与 sequentially consistent ordering 不同, 因此可以按情况使用榨干效能).
DATA DEPENDENCY WITH ACQUIRE-RELEASE ORDERING AND MEMORY_ORDER_CONSUME
C++17 standard explicitly recommends that you do not use it.
It’s all about data dependencies. There are two new relations that deal with data dependencies: dependency-ordered-before and carries-a-dependency-to.
- carries-a-dependency-to applies strictly within a single thread and models the data dependency between operations. This operation is also transitive.
- dependency-ordered-before relationship can apply between threads. It’s introduced by using atomic load operations tagged with
memory_order_consume.- This is a special case of
memory_order_acquirethat limits the synchronized data to direct dependencies; a store operation (A) tagged withmemory_order_release,memory_order_acq_rel, ormemory_order_seq_cstis dependency-ordered-before a load operation (B) tagged withmemory_order_consumeif the consume reads the value stored. - Also transitive.
- 应用场景: where the atomic operation loads a pointer to some data. By using
memory_order_consumeon the load andmemory_order_releaseon the prior store, you ensure that the pointed-to data is correctly synchronized, without imposing any synchronization requirements on any other nondependent data.
- This is a special case of
1 |
|
上面的例子中 assert(x->i==42); assert(x->s=="hello"); 肯定不会 fire, 但是 assert(a.load(std::memory_order_relaxed)==99); 有可能 fire. 因为 a 并没有与 p 有依赖关系, 因此可以被 reordered.
如何打破 carrying the dependency(chain)
std::kill_dependency(): a simple function template that copies the supplied argument to the return value but breaks the dependency chain in doing so.- In real code, you should always use
memory_order_acquirewhere you might be tempted to usememory_order_consume, andstd::kill_dependencyis unnecessary.
5.3.4 Release sequences and synchronizes-with
the chain of operations constitutes a release sequence and the initial store synchronizes with (for memory_order_acquire or memory_order_seq_cst) or is dependency-ordered-before (for memory_order_consume) the final load.
1 |
|
图中的实线为 happens-before 关系, 虚线为 release sequence.
存在 release sequence 的意义是 thread a b 之间不会形成对 count.store() data race, RMW operation 以及 acquire-release semantics 保证了 release sequence 的实现.
PS. 这里的微观基础可能是 RMW 操作的基础是类似与 compare-and-swap(CAS) 的操作, 这样就可以实现 no data race. 当然实现的微观基础也有可能是 semaphore 来避免 starvation.
5.3.5 Fences
Fences are also commonly called memory barriers, and they get their name because they put a line in the code that certain operations can’t cross.
实际意义: relaxed operations on separate variables can usually be freely reordered by the compiler or the hardware. Fences restrict this freedom and introduce happens-before and synchronizes-with relationships that weren’t present before.
1 |
|
添加的 std::atomic_thread_fence(std::memory_order_release); 与 std::atomic_thread_fence(std::memory_order_acquire); 可以像对 atomic variables 进行 acquire-release 操作一样实现对顺序的限制.
it’s important to note that the synchronization point is the fence itself. 注意 fence 的放置位置!
5.3.6 Ordering non-atomic operations with atomics
1 |
|
有了 fence, 即便不是 atomic 类型数据也可以被限制顺序.
5.3.7 Ordering non-atomic operations
atomic 与 non-atomic 语句混合的情况下的顺序: If a non-atomic operation is sequenced before an atomic operation, and that atomic operation happens before an operation in another thread, the non-atomic operation also happens before that operation in the other thread.
这样就把中层一点的同步实现与顶层的用户接口的逻辑对接起来了: Each of the synchronization mechanisms described in chapters 2, 3, and 4 will provide ordering guarantees in terms of the synchronizes-with relationship.
下面的罗列可能有点枯燥, 但是可以理清很多我们认为是理所当然但其实可以细扣的顺序问题(也相当于一次汇总复习了).
std::thread- The completion of the
std::threadconstructor synchronizes with the invocation of the supplied function or callable object on the new thread. - The completion of a thread synchronizes with the return from a successful call to join on the
std::threadobject that owns that thread.
- The completion of the
std::mutex,std::timed_mutex,std::recursive_mutex,std::recursive_timed_mutex- All calls to
lockandunlock, and successful calls totry_lock,try_lock_for, ortry_lock_until, on a given mutex object form a single total order: the lock order of the mutex. - A call to
unlockon a given mutex object synchronizes with a subsequent call to lock, or a subsequent successful call totry_lock,try_lock_for, ortry_lock_until, on that object in the lock order of the mutex. - Failed calls to
try_lock,try_lock_for, ortry_lock_untildo not participate in any synchronization relationships.
- All calls to
std::shared_mutex,std::shared_timed_mutex- All calls to
lock,unlock,lock_shared, andunlock_shared, and successful calls totry_lock,try_lock_for,try_lock_until,try_lock_shared,try_lock_shared_for, ortry_lock_shared_until, on a given mutex object form a single total order: the lock order of the mutex. - A call to
unlockon a given mutex object synchronizes with a subsequent call tolockorshared_lock, or a successful call totry_lock,try_lock_for,try_lock_until,try_lock_shared,try_lock_shared_for, ortry_lock_shared_until, on that object in the lock order of the mutex. - Failed calls to
try_lock,try_lock_for,try_lock_until,try_lock_shared,try_lock_shared_for, ortry_lock_shared_untildo not participate in any synchronization relationships.
- All calls to
std::promise,std::futureANDstd::shared_future- The successful completion of a call to
set_valueorset_exceptionon a givenstd::promiseobject synchronizes with a successful return from a call towaitorget, or a call towait_fororwait_untilthat returnsstd::future_status::readyon a future that shares the same asynchronous state as the promise. - The destructor of a given
std::promiseobject that stores anstd::future_errorexception in the shared asynchronous state associated with the promise synchronizes with a successful return from a call towaitorget, or a call towait_fororwait_untilthat returnsstd::future_status::readyon a future that shares the same asynchronous state as the promise.
- The successful completion of a call to
std::packaged_task,std::futureANDstd::shared_future- The successful completion of a call to the function call operator of a given
std::packaged_taskobject synchronizes with a successful return from a call towaitorget, or a call towait_fororwait_untilthat returnsstd::future_status::readyon a future that shares the same asynchronous state as the packaged task. - The destructor of a given
std::packaged_taskobject that stores anstd::future_errorexception in the shared asynchronous state associated with the packaged task synchronizes with a successful return from a call towaitorget, or a call towait_fororwait_untilthat returnsstd::future_status::readyon a future that shares the same asynchronous state as the packaged task.
- The successful completion of a call to the function call operator of a given
std::async,std::futureANDstd::shared_future- The completion of the thread running a task launched via a call to
std::asyncwith a policy ofstd::launch::asyncsynchronizes with a successful return from a call towaitorget, or a call towait_fororwait_untilthat returnsstd::future_status::readyon a future that shares the same asynchronous state as the spawned task. - The completion of a task launched via a call to
std::asyncwith a policy ofstd::launch::deferredsynchronizes with a successful return from a call towaitorget, or a call towait_fororwait_untilthat returnsstd::future_status::readyon a future that shares the same asynchronous state as the promise.
- The completion of the thread running a task launched via a call to
std::experimental::future,std::experimental::shared_futureAND CONTINUATIONS- The event that causes an asynchronous shared state to become ready synchronizes with the invocation of a continuation function scheduled on that shared state.
- The completion of a continuation function synchronizes with a successful return from a call to
waitorget, or a call towait_fororwait_untilthat returnsstd::future_status::readyon a future that shares the same asynchronous state as the future returned from the call to then that scheduled the continuation, or the invocation of any continuation scheduled on that future.
std::experimental::latch- The invocation of each call to
count_downorcount_down_and_waiton a given instance ofstd::experimental::latchsynchronizes with the completion of each successful call towaitorcount_down_and_waiton that latch.
- The invocation of each call to
std::experimental::barrier- The invocation of each call to
arrive_and_waitorarrive_and_dropon a given instance ofstd::experimental::barriersynchronizes with the completion of each subsequent successful call toarrive_and_waiton that barrier.
- The invocation of each call to
std::experimental::flex_barrier- The invocation of each call to
arrive_and_waitorarrive_and_dropon a given instance ofstd::experimental::flex_barriersynchronizes with the completion of each subsequent successful call toarrive_and_waiton that barrier. - The invocation of each call to
arrive_and_waitorarrive_and_dropon a given instance ofstd::experimental::flex_barriersynchronizes with the subsequent invocation of the completion function on that barrier. - The return from the completion function on a given instance of
std::experimental::flex_barriersynchronizes with the completion of each call toarrive_and_waiton that barrier that was blocked waiting for that barrier when the completion function was invoked.
- The invocation of each call to
std::condition_variableANDstd::condition_variable_any- Condition variables do not provide any synchronization relationships. They are optimizations over busy-wait loops, and all the synchronization is provided by the operations on the associated mutex.
C++并发实战-第五章-总学习笔记第3
https://www.chuxin911.com/Notes_On_C++_Concurrency_in_Action_3_20221001/