c++并发

www.cnblogs.com/haippy/p/3284540.html

g++-4.8(-std=c++11)安装

$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
$ sudo apt-get update
$ sudo apt-get install g++-4.8

Once installed, run following commands one by one to use gcc 4.8 instead of previous version.

sudo update-alternatives --remove-all gcc
sudo update-alternatives --remove-all g++
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 20
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 20
sudo update-alternatives --config gcc
sudo update-alternatives --config g++

------------------------------------------------------------------------

关于乱序

说到内存模型,首先需要明确一个普遍存在,但却未必人人都注意到的事实:程序通常并不是总按着照源码中的顺序一一执行,此谓之乱序,乱序产生的原因可能有好几种:

  1. 编译器出于优化的目的,在编译阶段将源码的顺序进行交换。
  2. 程序执行期间,指令流水被 cpu 乱序执行。
  3. inherent cache 的分层及刷新策略使得有时候某些写读操作的从效果上看,顺序被重排。

以上乱序现象虽然来源不同,但从源码的角度,对上层应用程序来说,他们的效果其实相同:写出来的代码与最后被执行的代码是不一致的。这个事实可能会 让人很惊讶:有这样严重的问题,还怎么写得出正确的代码?这担忧是多余的了,乱序的现象虽然普遍存在,但它们都有很重要的一个共同点:在单线程执行的情况 下,乱序执行与不乱序执行,最后都会得出相同的结果 (both end up with the same observable result), 这是乱序被允许出现所需要遵循的首要原则,也是为什么乱序虽然一直存在但却多数程序员大部分时间都感觉不到的根本原因。

乱序的出现说到底是编译器,CPU 等为了让你程序跑得更快而作出无限努力的结果,程序员们应该为它们的良苦用心抹一把泪。

从乱序的种类来看,乱序主要可以分为如下4种:

  1. 写写乱序(store store), 前面的写操作被放到了后面的操作之后,比如:

    a = 3;
    b = 4;
    被乱序为:
    b = 4;
    a = 3;
  2. 写读乱序(store load),前面的写操作被放到了后面的读操作之后,比如:

    a = 3;
    load(b);
    被乱序为
    load(b);
    a = 3;
  3. 读读乱序(load load), 前面的读操作被放到了后一个读操作之后,比如:

    load(a);
    load(b);
    被乱序为:
    load(b);
    load(a);
  4. 读写乱序(load store), 前面的读操作被放到了后一个写操作之后,比如:

    load(a);
    b = 4;
    被乱序为:
    b = 4;
    load(a);

程序的乱序在单线程的世界里多数时候并没有引起太多引人注意的问题,但在多线程的世界里,这些乱序就制造了特别的麻烦,究其原因,最主要的有2个:

  1. 并发不能保证修改和访问共享变量的操作原子性,使得一些中间状态暴露了出去,因此像 mutex,各种 lock 之类的东西在写多线程时被频繁地使用。
  2. 变量被修改后,该修改未必能被另一个线程及时观察到,因此需要“同步”。

解决同步问题就需要确定内存模型,也就是需要确定线程间应该怎么通过共享内存来进行交互

 

 

内存模型

内存模型所要表达的内容主要是怎么描述一个内存操作的效果,在各个线程间的可见性的问题。修改操作的效果不能及时被别的线程看见的原因有很多,比较 明显的一个是,对计算机来说,通常内存的写操作相对于读操作是昂贵很多很多的,因此对写操作的优化是提升性能的关键,而这些对写操作的种种优化,导致了一 个很普遍的现象出现:写操作通常会在 CPU 内部的 cache 中缓存起来。这就导致了在一个 CPU 里执行一个写操作之后,该操作导致的内存变化却不一定会马上就被另一个 CPU 所看到,这从另一个角度讲,效果上其实就是读写乱序了。

cpu1 执行如下:
a = 3;
cpu2 执行如下:
load(a);

对如上代码,假设 a 的初始值是 0, 然后 cpu1 先执行,之后 cpu2 再执行,假设其中读写都是原子的,那么最后 cpu2 如果读到 a = 0 也其实不是什么奇怪事情。很显然,这种在某个线程里成功修改了全局变量,居然在另一个线程里看不到效果的后果是很严重的。

因此必须要有必要的手段对这种修改公共变量的行为进行同步。

c++11 中的 atomic library 中定义了以下6种语义来对内存操作的行为进行约定,这些语义分别规定了不同的内存操作在其它线程中的可见性问题:

 typedef enum memory_order {
    memory_order_relaxed,   \\ 不指定内存屏障,所以内存操作执行时可能是乱序的。
    memory_order_acquire,   \\ 按照我理解就是插入一个 内存读屏障,保证之前的读操作先一步完成。清空自己cpu上"invalidate queues"
    memory_order_release,    \\ 按照我理解就是插入一个 内存写屏障,保证之前的写操作的顺序一定 。清空自己cpu上的“store buffer"
    memory_order_consume,    \\类似memory_order_acquire,但只对依赖的指定数据起作用。
    memory_order_acq_rel,    \\ 同时插入读写两个屏障。  清空自己cpu上 的 “ store buffer""invalidate queues"
    memory_order_seq_cst    \\ 保证某个结果在不同cpu上的一致性。这个会清空所有cpu上的读写同步消息队列 “store buffer""invalidate queues"
} memory_order;

http://blog.csdn.net/chen19870707/article/details/39896655

看过了很多介绍指令重排序的文章,可惜由于自己硬件和计算机理论知识缺乏,很难理解深层次的奥秘和实现原理。不过也有很多帖子,讲的浅显易懂,使用的例子很形象。大牛就是能用简单的解释和通俗的比喻,给我们讲明白很高深的东西。这里做个摘抄和总结,和大家分享下,希望大家能够对指令重排序有个形象的认识,不至于在并发编程中犯一些简单的错误。如果理解有错误,希望看到的大神指正。

从源码变成可以被机器(或虚拟机)识别的程序,至少要经过编译期和运行期。重排序分为两类:编译期重排序和运行期重排序(乱序执行),分别对应编译时和运行时环境。由于重排序的存在,指令实际的执行顺序,并不是源码中看到的顺序。


1.编译器的重排序

编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序。下面的例子来自并发编程网的文章

“编译期重排序的典型就是通过调整指令顺序,在不改变程序语义的前提下,尽可能减少寄存器的读取、存储次数,充分复用寄存器的存储值。假设第一条指令计算一个值赋给变量A并存放在寄存器中,第二条指令与A无关但需要占用寄存器(假设它将占用A所在的那个寄存器),第三条指令使用A的值且与第二条指令无关。那么如果按照顺序一致性模型,A在第一条指令执行过后被放入寄存器,在第二条指令执行时A不再存在,第三条指令执行时A重新被读入寄存器,而这个过程中,A的值没有发生变化。通常编译器都会交换第二和第三条指令的位置,这样第一条指令结束时A存在于寄存器中,接下来可以直接从寄存器中读取A的值,降低了重复读取的开销。”

另一种编译器优化:在循环中读取变量的时候,为提高存取速度,编译器会先把变量读取到一个寄存器中;以后再取该变量值时,就直接从寄存器中取,不会再从内存中取值了。这样能够减少不必要的访问内存。但是提高效率的同时,也引入了新问题。如果别的线程修改了内存中变量的值,那么由于寄存器中的变量值一直没有发生改变,很有可能会导致循环不能结束。编译器进行代码优化,会提高程序的运行效率,但是也可能导致错误的结果。所以程序员需要防止编译器进行错误的优化。


2.指令间的直接依赖关系

编译器和处理器可能会对操作做重排序,但是要遵守数据依赖关系,编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。如果两个操作访问同一个变量,且这两个操作中有一个为写操作,此时这两个操作之间就存在数据依赖性。数据依赖分下列三种类型:
名称 代码示例说明
写后读 a = 1;b = a;写一个变量之后,再读这个位置。
写后写 a = 1;a = 2;写一个变量之后,再写这个变量。
读后写 a = b;b = 1;读一个变量之后,再写这个变量。
上面三种情况,只要重排序两个操作的执行顺序,程序的执行结果将会被改变。像这种有直接依赖关系的操作,是不会进行重排序的。特别注意:这里说的依赖关系仅仅是在单个线程内。

//写线程
public void writer() {
    a = 1;                   
    flag = true;             
}

//读线程
Public void reader() {
    if (flag) {               
        int i =  a * a;        
    }
}


虽然从读线程和写线程的逻辑关系上来说,写线程不能进行重排序,否则读线程会产生错误的结果;但是实际上写线程还是可能发生重排序的,因为从写线程自身的角度来看,a和flag的写操作完全没有依赖关系,可以随意重排序。编译器没有那么只能,它只能将依赖分析限制在单线程中,不能跨线程进行依赖分析。依赖关系主要是摘抄这篇文章


3.指令间的隐式依赖关系

编译器和CPU都必须保证程序上下文的因果关系不发生改变。因此,在绝大多数情况下,我们写程序都不会去考虑乱序所带来的影响。但是有些程序逻辑,单纯从上下文是看不出它们的因果关系的。比如:
*addr=5;

val=*data;
从表面上看,addr和data是没有什么联系的,完全可以放心的去乱序执行。但是如果这是在某某设备驱动程序中,这两个变量却可能对应到设备的地址端口和数据端口。并且,这个设备规定了,当你需要读写设备上的某个寄存器时,先将寄存器编号设置到地址端口,然后就可以通过对数据端口的读写而操作到对应的寄存器。那么这么一来,对前面那两条指令的乱序执行就可能造成错误。对于这样的逻辑,我们姑且将其称作隐式因果关系;而指令与指令之间直接的输入输出依赖,也姑且称作显式因果关系。CPU的乱序执行或者编译器的重排序是以保持显式因果关系不变为前提的,但是它们都无法识别隐式因果关系。再举个例子:
obj->data = xxx;

obj->ready = 1;
当设置了data之后,记下标志,然后在另一个线程中可能执行:
if (obj->ready)

    do_something(obj->data);
虽然这个代码看上去有些别扭,但是似乎没错。不过,考虑到乱序,如果标志被置位先于data被设置,那么结果很可能就杯具了。因为从字面上看,前面的那两条指令其实并不存在显式的因果关系,乱序是有可能发生的。总的来说,如果程序具有显式的因果关系的话,乱序一定会尊重这些关系;否则,乱序就可能打破程序原有的逻辑。这时候,就需要使用屏障来抑制乱序,以维持程序所期望的逻辑。这段文字摘抄自这篇文章


4.CPU的重排序(指令乱序执行)

现在的CPU一般采用流水线来执行指令。一个指令的执行被分成:取指、译码、访存、执行、写回、等若干个阶段。然后,多条指令可以同时存在于流水线中,同时被执行。指令流水线并不是串行的,并不会因为一个耗时很长的指令在“执行”阶段呆很长时间,而导致后续的指令都卡在“执行”之前的阶段上。相反,流水线是并行的,多个指令可以同时处于同一个阶段,只要CPU内部相应的处理部件未被占满即可。比如说CPU有一个加法器和一个除法器,那么一条加法指令和一条除法指令就可能同时处于“执行”阶段, 而两条加法指令在“执行”阶段就只能串行工作。

然而,这样一来,乱序可能就产生了。比如一条加法指令原本出现在一条除法指令的后面,但是由于除法的执行时间很长,在它执行完之前,加法可能先执行完了。再比如两条访存指令,可能由于第二条指令命中了cache而导致它先于第一条指令完成。一般情况下,指令乱序并不是CPU在执行指令之前刻意去调整顺序。CPU总是顺序的去内存里面取指令,然后将其顺序的放入指令流水线。但是指令执行时的各种条件,指令与指令之间的相互影响,可能导致顺序放入流水线的指令,最终乱序执行完成。这就是所谓的“顺序流入,乱序流出”。


指令流水线除了在资源不足的情况下会卡住之外(如前所述的一个加法器应付两条加法指令的情况),指令之间的相关性也是导致流水线阻塞的重要原因。CPU的乱序执行并不是任意的乱序,而是以保证程序上下文因果关系为前提的。有了这个前提,CPU执行的正确性才有保证。比如:
a++;

b=f(a);

c--;
由于b=f(a)这条指令依赖于前一条指令a++的执行结果,所以b=f(a)将在“执行”阶段之前被阻塞,直到a++的执行结果被生成出来;而c--跟前面没有依赖,它可能在b=f(a)之前就能执行完。(注意,这里的f(a)并不代表一个以a为参数的函数调用,而是代表以a为操作数的指令。C语言的函数调用是需要若干条指令才能实现的,情况要更复杂些)。


像这样有依赖关系的指令如果挨得很近,后一条指令必定会因为等待前一条执行的结果,而在流水线中阻塞很久,占用流水线的资源。而编译器的乱序,作为编译优化的一种手段,则试图通过指令重排将这样的两条指令拉开距离, 以至于后一条指令进入CPU的时候,前一条指令结果已经得到了,那么也就不再需要阻塞等待了。比如将指令重排为:
a++;

c--;

b=f(a);
相比于CPU的乱序,编译器的乱序才是真正对指令顺序做了调整。但是编译器的乱序也必须保证程序上下文的因果关系不发生改变。


由于重排序和乱序执行的存在,如果在并发编程中,没有做好共享数据的同步,很容易出现各种看似诡异的问题。

#include <atomic>
#include <thread>
#include <assert.h>

std::atomic<bool> x,y;
std::atomic<int> z;

void write_x_then_y()
{
    x.store(true,std::memory_order_relaxed);   //1
    y.store(true,std::memory_order_release);   //2   //保证 第//1句的x写入在y的写入之前
}

void read_y_then_x()
{
    while(!y.load(std::memory_order_acquire));  //3  //保证 y的读取在 第//4句x的读取之前。所以  如果y看到修改后的值,肯定 第//4句看到的也是x的新的值了。
    if(x.load(std::memory_order_relaxed))     //4
        ++z;
}

int main()
{
    x=false;
    y=false;
    z=0;
    std::thread a(write_x_then_y);
    std::thread b(read_y_then_x);
    a.join();
    b.join();
    assert(z.load() != 0);    //5    //这个肯定通过的了。
}

 

relaxed 语义

首先是 relaxed 语义,这表示一种最宽松的内存操作约定,该约定其实就是不进行约定,以这种方式修改内存时,不需要保证该修改会不会及时被其它线程看到,也不对乱序做任何 要求,因此当对公共变量以 relaxed 方式进行读写时,编译器,cpu 等是被允许按照任意它们认为合适的方式来加以优化处理的。

release-acquire 语义

如果你曾经去看过别的介绍内存模型相关的文章,你一定会发现 release 总是和 acquire 放到一起来讲,这并不是偶然。事实上,release 和 acquire 是相辅相承的,它们必须配合起来使用,这俩是一个 “package deal”, 分开使用则完全没有意义。具体到其中, release 用于进行写操作,acquire 则用于进行读操作,它们结合起来表示这样一个约定:

如果一个线程A对一块内存 m 以 release 的方式进行修改,那么在线程 A 中,所有在该 release 操作之前进行的内存操作,都在另一个线程 B 对内存 m 以 acquire 的方式进行读取之后,变得可见。

举个粟子,假设线程 A 执行如下指令:

a.store(3);
b.store(4);
m.store(5, release);

线程 B 执行如下:

e.load();
f.load();
m.load(acquire);
g.load();
h.load();

如上,假设线程 A 先执行,线程 B 后执行, 因为线程 A 中对 m 以 release 的方式进行修改, 而线程 B 中以 acquire 的方式对 m 进行读取,所以当线程 B 执行完 m.load(acquire) 之后, 线程 B 必须已经能看到 a == 3, b == 4. 以上死板的描述事实上还传达了额外的不那么明显的信息:

  • release 和 acquire 是相对两个线程来说的,它约定的是两个线程间的相对行为:如果其中一个线程 A 以 release 的方式修改公共变量 m, 另一个线程 B 以 acquire 的方式时读取该 m 时,要有什么样的后果,但它并不保证,此时如果还有另一个线程 C 以非 acquire 的方式来读取 m 时,会有什么后果。

  • 一定程度阻止了乱序的发生,因为要求 release 操作之前的所有操作都在另一个线程 acquire 之后可见,那么:
    • release 操作之前的所有内存操作不允许被乱序到 release 之后。
    • acquire 操作之后的所有内存操作不允许被乱序到 acquire 之前。

而在对它们的使用上,有几点是特别需要注意和强调的:

  1. release 和 acquire 必须配合使用,分开单独使用是没有意义。
  2. release 只对写操作(store) 有效,对读 (load) 是没有意义的。
  3. acquire 则只对读操作有效,对写操作是没有意义的。

现代的处理器通常都支持一些 read-modify-write 之类的指令,对这种指令,有时我们可能既想对该操作 执行 release 又要对该操作执行 acquire,因此 c++11 中还定义了 memory_order_acq_rel,该类型的操作就是 release 与 acquire 的结合,除前面提到的作用外,还起到了 memory barrier 的功能。

sequential consistency

sequential consistency 相当于 release + acquire 之外,还加上了一个对该操作加上全局顺序的要求,这是什么意思呢?

简单来说就是,对所有以 memory_order_seq_cst 方式进行的内存操作,不管它们是不是分散在不同的 cpu 中同时进行,这些操作所产生的效果最终都要求有一个全局的顺序,而且这个顺序在各个相关的线程看起来是一致的。

举个粟子,假设 a, b 的初始值都是0:

线程 A 执行:

a.store(3, seq_cst);

线程 B 执行:

b.store(4, seq_cst);

如上对 a 与 b 的修改虽然分别放在两个线程里同时进行,但是这多个动作毕竟是非原子的,因此这些操作地进行在全局上必须要有一个先后顺序:

  1. 先修改a, 后修改 b,或
  2. 先修改b, 把整个a。

而且这个顺序是固定的,必须在其它任意线程看起来都是一样,因此 a == 0 && b == 4 与 a == 3 && b == 0 不允许同时成立。

 

 

#include <iostream>       // std::cout
#include <atomic>         // std::atomic, std::memory_order_relaxed
#include <thread>         // std::thread

std::atomic<int> foo(0); // 全局的原子对象 foo

void set_foo(int x)
{
    foo.store(x, std::memory_order_relaxed); // 设置(store) 原子对象 foo 的值
}

void print_foo()
{
    int x;
    do {
        x = foo.load(std::memory_order_relaxed); // 读取(load) 原子对象 foo 的值
        usleep(10);
        std::cout << "foo: " << x << '\n';
    } while (x == 0);
}

int main ()
{
    std::thread first(print_foo); // 线程 first 打印 foo 的值
    usleep(200);
    std::thread second(set_foo, 10); // 线程 second 设置 foo 的值
    first.join();
    second.join();
    return 0;
}

mutian@mutian:~/soft/compile$ ./a.out
foo: 0
foo: 0
foo: 0
foo: 0
foo: 10

#include <iostream>       // std::cout
#include <atomic>         // std::atomic, std::memory_order_relaxed
#include <thread>         // std::thread
#include <assert.h>

std::atomic<std::string*> ptr;
int data;

void producer()
{
    std::cout << "producer\n";
    std::string* p = new std::string("Hello");          // A  
    data = 42;                          // B  
    std::cout << "store\n";
    ptr.store(p, std::memory_order_release);            // C  
}

void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_acquire))) {
        std::cout << "load\n";
    }

    assert(*p2 == "Hello");                 // E  
    assert(data == 42);                     // F  
}

int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

load
load
load
load
load
load
load
load
load
store
load

    void producer()  
    {  
        std::string* p = new std::string("Hello");          // A  
        data = 42;                          // B  
        ptr.store(p, std::memory_order_release);            // C  
    }  
       
    void consumer()  
    {  
        std::string* p2;  
        while (!(p2 = ptr.load(std::memory_order_consume)))     // D  
            ;  
        assert(*p2 == "Hello");                 // E  
        assert(data == 42);                     // F  
    } 

那么我们还能那么轻易地推导出A happens-before E、B happens-before F吗?答案是:A、E关系成立,而B、F关系破裂。根据我们之前的定义,E depends-on D,从而可以推导出,接着就是水到渠成了。反观D、F之间并不存在这种依赖关系。因此,这里的E永远不会fail,而F有可能fail。

TIPS:Release-Consume ordering难度系数最高,强烈不推荐初学者使用,很多大师级人物都在这上面栽过跟头,当然,它的系统开销可能小于Release-Acquire ordering,适用于极致追求性能的场景,前提是你得能够hold住它。

-----------------------------------------------------------------------------------------------------------------

std::atomic_flag

<atomic> 头文件中最简单的原子类型: atomic_flag。atomic_flag 一种简单的原子布尔类型,只支持两种操作,test-and-set 和 clear。

std::atomic_flag 只有默认构造函数,拷贝构造函数已被禁用,因此不能从其他的 std::atomic_flag 对象构造一个新的 std::atomic_flag 对象。
如果在初始化时没有明确使用 ATOMIC_FLAG_INIT初始化,那么新创建的 std::atomic_flag 对象的状态是未指定的(unspecified)(既没有被 set 也没有被 clear)另外,atomic_flag不能被拷贝,也不能 move 赋值。
ATOMIC_FLAG_INIT: 如果某个 std::atomic_flag 对象使用该宏初始化,那么可以保证该 std::atomic_flag 对象在创建时处于 clear 状态。
std::atomic_flag::test_and_set 介绍

bool test_and_set (memory_order sync = memory_order_seq_cst) volatile noexcept;
bool test_and_set (memory_order sync = memory_order_seq_cst) noexcept;

test_and_set() 函数检查 std::atomic_flag 标志,如果 std::atomic_flag 之前没有被设置过,则设置 std::atomic_flag 的标志,并返回先前该 std::atomic_flag 对象是否被设置过,如果之前 std::atomic_flag 对象已被设置,则返回 true,否则返回 false。

test-and-set 操作是原子的(因此 test-and-set 是原子 read-modify-write (RMW)操作)。

test_and_set 可以指定 Memory Order(后续的文章会详细介绍 C++11 的 Memory Order,此处为了完整性列出 test_and_set 参数 sync 的取值),取值如下:

 

Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent

 

#include <iostream>              // std::cout
#include <atomic>                // std::atomic, std::atomic_flag, ATOMIC_FLAG_INIT
#include <thread>                // std::thread, std::this_thread::yield
#include <vector>                // std::vector

std::atomic<bool> ready(false);    // can be checked without being set
std::atomic_flag winner = ATOMIC_FLAG_INIT;    // always set when checked

void count1m(int id)
{
    while (!ready) {
        std::this_thread::yield();
    } // 等待主线程中设置 ready 为 true.

    for (int i = 0; i < 1000000; ++i) {
    } // 计数.

    // 如果某个线程率先执行完上面的计数过程,则输出自己的 ID.
    // 此后其他线程执行 test_and_set 是 if 语句判断为 false,
    // 因此不会输出自身 ID.
    if (!winner.test_and_set()) {
        std::cout << "thread #" << id << " won!\n";
    }
};

int main()
{
    std::vector<std::thread> threads;
    std::cout << "spawning 10 threads that count to 1 million...\n";
    for (int i = 1; i <= 10; ++i)
        threads.push_back(std::thread(count1m, i));
    ready = true;

    for (auto & th:threads)
        th.join();

    return 0;
}

 

mutian@mutian:~/soft/compile$ ./a.out
spawning 10 threads that count to 1 million...
thread #10 won!
mutian@mutian:~/soft/compile$ ./a.out
spawning 10 threads that count to 1 million...
thread #9 won!
mutian@mutian:~/soft/compile$ ./a.out
spawning 10 threads that count to 1 million...
thread #6 won!

基于 std::atomic 模板类型的 C 风格 API

template (1)
template <class T> bool atomic_is_lock_free (const volatile atomic<T>* obj) noexcept;
template <class T> bool atomic_is_lock_free (const atomic<T>* obj) noexcept;
overloads (2)
bool atomic_is_lock_free (const volatile A* obj) noexcept;
bool atomic_is_lock_free (const A* obj) noexcept;
template (1)
template <class T> void atomic_init (volatile atomic<T>* obj, T val) noexcept;
template <class T> void atomic_init (atomic<T>* obj, T val) noexcept;
overloads (2)
void atomic_init (volatile A* obj, T val) noexcept;
void atomic_init (A* obj, T val) noexcept;
template (1)
template <class T> void atomic_store (volatile atomic<T>* obj, T val) noexcept;
template <class T> void atomic_store (atomic<T>* obj, T val) noexcept;
overloads (2)
void atomic_store (volatile A* obj, T val) noexcept;
void atomic_store (A* obj, T val) noexcept;
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_release Release
memory_order_seq_cst Sequentially consistent
template (1)
template <class T> T atomic_load (const volatile atomic<T>* obj) noexcept;
template <class T> T atomic_load (const atomic<T>* obj) noexcept;
overloads (2)
T atomic_load (const volatile A* obj) noexcept;
T atomic_load (const A* obj) noexcept;
template (1)
template <class T>
T atomic_load_explicit (const volatile atomic<T>* obj, memory_order sync) noexcept;
template <class T>
T atomic_load_explicit (const atomic<T>* obj, memory_order sync) noexcept;
overloads (2)
T atomic_load_explicit (const volatile A* obj, memory_order sync) noexcept;
T atomic_load_explicit (const A* obj, memory_order sync) noexcept;
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_seq_cst Sequentially consistent
template (1)
template <class T> T atomic_exchange (volatile atomic<T>* obj, T val) noexcept;
template <class T> T atomic_exchange (atomic<T>* obj, T val) noexcept;
overloads (2)
T atomic_exchange (volatile A* obj, T val) noexcept;
T atomic_exchange (A* obj, T val) noexcept;
template (1)
template <class T>
T atomic_store_explicit (volatile atomic<T>* obj, T val, memory_order sync) noexcept;
template <class T>
T atomic_store_explicit (atomic<T>* obj, T val, memory_order sync) noexcept;
overloads (2)
T atomic_store_explicit (volatile A* obj, T val, memory_order sync) noexcept;
T atomic_store_explicit (A* obj, T val, memory_order sync) noexcept;
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent
template (1)
template <class T>
bool atomic_compare_exchange_weak (volatile atomic<T>* obj, T* expected, T val) noexcept;
template <class T>
bool atomic_compare_exchange_weak (atomic<T>* obj, T* expected, T val) noexcept;
overloads (2)
bool atomic_compare_exchange_weak (volatile A* obj, T* expected, T val) noexcept;
bool atomic_compare_exchange_weak (A* obj, T* expected, T val) noexcept;
  • 相等,则用 val 替换原子对象的旧值。
  • 不相等,则用原子对象的旧值替换 expected ,因此调用该函数之后,如果被该原子对象封装的值与参数 expected 所指定的值不相等,expected 中的内容就是原子对象的旧值。
template (1)
template <class T>
bool atomic_compare_exchange_weak_explicit (volatile atomic<T>* obj,
        T* expected, T val, memory_order success, memory_order failure) noexcept;
template <class T>
bool atomic_compare_exchange_weak_explicit (atomic<T>* obj,
        T* expected, T val, memory_order success, memory_order failure) noexcept;
overloads (2)
bool atomic_compare_exchange_weak_explicit (volatile A* obj,
        T* expected, T val, memory_order success, memory_order failure) noexcept;
bool atomic_compare_exchange_weak_explicit (A* obj,
        T* expected, T val, memory_order success, memory_order failure) noexcept;
  • 相等,则用 val 替换原子对象的旧值。
  • 不相等,则用原子对象的旧值替换 expected ,因此调用该函数之后,如果被该原子对象封装的值与参数 expected 所指定的值不相等,expected 中的内容就是原子对象的旧值。
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent
template (1)
template <class T>
bool atomic_compare_exchange_strong (volatile atomic<T>* obj, T* expected, T val) noexcept;
template <class T>
bool atomic_compare_exchange_strong (atomic<T>* obj, T* expected, T val) noexcept;
overloads (2)
bool atomic_compare_exchange_strong (volatile A* obj, T* expected, T val) noexcept;
bool atomic_compare_exchange_strong (A* obj, T* expected, T val) noexcept;
  • 相等,则用 val 替换原子对象的旧值。
  • 不相等,则用原子对象的旧值替换 expected ,因此调用该函数之后,如果被该原子对象封装的值与参数 expected 所指定的值不相等,expected 中的内容就是原子对象的旧值。
template (1)
template <class T>
bool atomic_compare_exchange_strong_explicit (volatile atomic<T>* obj,
        T* expected, T val, memory_order success, memory_order failure) noexcept;
template <class T>
bool atomic_compare_exchange_strong_explicit (atomic<T>* obj,
        T* expected, T val, memory_order success, memory_order failure) noexcept;
overloads (2)
bool atomic_compare_exchange_strong_explicit (volatile A* obj,
        T* expected, T val, memory_order success, memory_order failure) noexcept;
bool atomic_compare_exchange_strong_explicit (A* obj,
        T* expected, T val, memory_order success, memory_order failure) noexcept;
  • 相等,则用 val 替换原子对象的旧值。
  • 不相等,则用原子对象的旧值替换 expected ,因此调用该函数之后,如果被该原子对象封装的值与参数 expected 所指定的值不相等,expected 中的内容就是原子对象的旧值。
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent
template (integral) (1)
template <class T> T atomic_fetch_add (volatile atomic<T>* obj, T val) noexcept;
template <class T> T atomic_fetch_add (atomic<T>* obj, T val) noexcept;
template (pointer) (2)
template <class U> U* atomic_fetch_add (volatile atomic<U*>* obj, ptrdiff_t val) noexcept;
template <class U> U* atomic_fetch_add (atomic<U*>* obj, ptrdiff_t val) noexcept;
overloads (3)
T atomic_fetch_add (volatile A* obj, M val) noexcept;
T atomic_fetch_add (A* obj, M val) noexcept;
template (integral) (1)
template <class T>
T atomic_fetch_add_explicit (volatile atomic<T>* obj,
                             T val, memory_order sync) noexcept;
template <class T>
T atomic_fetch_add_explicit (atomic<T>* obj,
                             T val, memory_order sync) noexcept;
template (pointer) (2)
template <class U>
U* atomic_fetch_add_explicit (volatile atomic<U*>* obj,
                              ptrdiff_t val, memory_order sync) noexcept;
template <class U>
U* atomic_fetch_add_explicit (atomic<U*>* obj,
                              ptrdiff_t val, memory_order sync) noexcept;
overloads (3)
T atomic_fetch_add_explicit (volatile A* obj, M val, memory_order sync) noexcept;
T atomic_fetch_add_explicit (A* obj, M val, memory_order sync) noexcept;
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent
template (integral) (1)
template <class T> T atomic_fetch_sub (volatile atomic<T>* obj, T val) noexcept;
template <class T> T atomic_fetch_sub (atomic<T>* obj, T val) noexcept;
template (pointer) (2)
template <class U> U* atomic_fetch_sub (volatile atomic<U*>* obj, ptrdiff_t val) noexcept;
template <class U> U* atomic_fetch_sub (atomic<U*>* obj, ptrdiff_t val) noexcept;
overloads (3)
T atomic_fetch_sub (volatile A* obj, M val) noexcept;
T atomic_fetch_sub (A* obj, M val) noexcept;
template (integral) (1)
template <class T>
T atomic_fetch_sub_explicit (volatile atomic<T>* obj,
                             T val, memory_order sync) noexcept;
template <class T>
T atomic_fetch_sub_explicit (atomic<T>* obj,
                             T val, memory_order sync) noexcept;
template (pointer) (2)
template <class U>
U* atomic_fetch_sub_explicit (volatile atomic<U*>* obj,
                              ptrdiff_t val, memory_order sync) noexcept;
template <class U>
U* atomic_fetch_sub_explicit (atomic<U*>* obj,
                              ptrdiff_t val, memory_order sync) noexcept;
overloads (3)
T atomic_fetch_sub_explicit (volatile A* obj, M val, memory_order sync) noexcept;
T atomic_fetch_sub_explicit (A* obj, M val, memory_order sync) noexcept;
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent
emplate (integral) (1)
template <class T> T atomic_fetch_and (volatile atomic<T>* obj, T val) noexcept;
template <class T> T atomic_fetch_and (atomic<T>* obj, T val) noexcept;
overloads (2)
T atomic_fetch_and (volatile A* obj, T val) noexcept;
T atomic_fetch_and (A* obj, T val) noexcept;
template (integral) (1)
template <class T>
T atomic_fetch_and_explicit (volatile atomic<T>* obj,
                             T val, memory_order sync) noexcept;
template <class T>
T atomic_fetch_and_explicit (atomic<T>* obj,
                             T val, memory_order sync) noexcept;
overloads (2)
T atomic_fetch_and_explicit (volatile A* obj, T val, memory_order sync) noexcept;
T atomic_fetch_and_explicit (A* obj, T val, memory_order sync) noexcept;
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent
template (integral) (1)
template <class T> T atomic_fetch_or (volatile atomic<T>* obj, T val) noexcept;
template <class T> T atomic_fetch_or (atomic<T>* obj, T val) noexcept;
overloads (2)
T atomic_fetch_or (volatile A* obj, T val) noexcept;
T atomic_fetch_or (A* obj, T val) noexcept;
template (integral) (1)
template <class T>
T atomic_fetch_or_explicit (volatile atomic<T>* obj,
                             T val, memory_order sync) noexcept;
template <class T>
T atomic_fetch_or_explicit (atomic<T>* obj,
                             T val, memory_order sync) noexcept;
overloads (2)
T atomic_fetch_or_explicit (volatile A* obj, T val, memory_order sync) noexcept;
T atomic_fetch_or_explicit (A* obj, T val, memory_order sync) noexcept;
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent
template (integral) (1)
template <class T> T atomic_fetch_xor (volatile atomic<T>* obj, T val) noexcept;
template <class T> T atomic_fetch_xor (atomic<T>* obj, T val) noexcept;
overloads (2)
T atomic_fetch_xor (volatile A* obj, T val) noexcept;
T atomic_fetch_xor (A* obj, T val) noexcept;
template (integral) (1)
template <class T>
T atomic_fetch_xor_explicit (volatile atomic<T>* obj,
                             T val, memory_order sync) noexcept;
template <class T>
T atomic_fetch_xor_explicit (atomic<T>* obj,
                             T val, memory_order sync) noexcept;
overloads (2)
T atomic_fetch_xor_explicit (volatile A* obj, T val, memory_order sync) noexcept;
T atomic_fetch_xor_explicit (A* obj, T val, memory_order sync) noexcept;
Memory Order 值Memory Order 类型
memory_order_relaxed Relaxed
memory_order_consume Consume
memory_order_acquire Acquire
memory_order_release Release
memory_order_acq_rel Acquire/Release
memory_order_seq_cst Sequentially consistent

与原子对象初始化相关的宏

posted @ 2015-12-15 20:51  牧 天  阅读(1401)  评论(0编辑  收藏  举报