keakon的涂鸦馆

// Thread 1           // Thread 2
x = 1                 y = 1
r1 = y                r2 = x

// Thread 1           // Thread 2
x = 1                 y = 1
barrier               barrier
r1 = y                r2 = x

// Thread 1           // Thread 2
x = 1                 r1 = y
y = 1                 r2 = x

// Thread 1    // Thread 2    // Thread 3    // Thread 4
x = 1          y = 1          r1 = x         r3 = y
                              r2 = y         r4 = x

1. 仅采用顺序一致性的原子。
   
2. 定义了竞争访问的结果，允许竞争读返回任何值，甚至是不相关的数据，这可能导致私有数据的泄露。
   
3. 定义了当原子和非原子操作在同一个内存地址使用时，以及当使用不同大小访问同一个内存地址时会发生什么。
   

1. 对于 sync.Mutex 或 sync.RWMutex 变量 l 和 n < m，第 n 次调用 l.Unlock() 发生于第 m 次调用 l.Lock() 的返回前。（也就是如果未被 Unlock() 的话，后续的 Lock() 是不会返回的。）
   
2. 如果原子（atomic）操作 A 的效果被原子操作 B 观测到了，那么 A 发生于 B 之前。（也就是 atomic.Load() 观测到了 atomic.Store() 的结果，那么 atomic.Store() 发生于 atomic.Load() 之前。）
   

type Once struct {
	done uint32
	m    Mutex
}

func (o *Once) Do(f func()) {
	if atomic.LoadUint32(&o.done) == 0 {
		o.doSlow(f)
	}
}

func (o *Once) doSlow(f func()) {
	o.m.Lock()
	defer o.m.Unlock()
	if o.done == 0 {
		defer atomic.StoreUint32(&o.done, 1)
		f()
	}
}

1. 为什么要用 if atomic.LoadUint32(&o.done) == 0 来判断，而不能直接用 if o.done == 0？
   因为不用原子操作或加锁的话，访问 o.done 可能获取到寄存器或缓存中的值，而不会观测到其他处理器对 o.done 的修改。
   不过以我的理解，如果对 o.done 的读未做同步，影响顶多是进入 doSlow() 中进行二次检查，然后这个处理器就会观测到最新的 o.done，以后不会再获取到旧值了。
   而且在实际的测试中，x86 的机器是可以立刻（小于 100 纳秒）观测到其他处理器对 o.done 的修改。
   
2. 为什么 doSlow() 中要用 Mutex 来加锁？
   首先，如果不加锁，初始化时如果有多个线程同时进入 doSlow()，则 f() 可能会被调用多次。其次，初始化后根本不会再进入 doSlow()，所以在这里面加锁并不会影响后续调用的性能。
   
3. 为什么 doSlow() 中的 if o.done == 0 不用原子操作？
   因为第一个获取到锁的线程执行完 atomic.StoreUint32(&o.done, 1) 才释放了锁，这个行为 happens-before 后续获取到锁的线程，这些线程一定会观测到 o.done == 1。
   
4. 为什么 doSlow() 中的 atomic.StoreUint32(&o.done, 1) 需要用原子操作？
   因为外面的 if atomic.LoadUint32(&o.done) == 0 使用了原子操作，里面用 atomic.StoreUint32(&o.done, 1) 才能与之形成 happens-before 的关系，即保证 doSlow() 返回后，后续对 atomic.LoadUint32(&o.done) 的调用都会返回 1。而如果不用原子操作，外面的 atomic.LoadUint32(&o.done) == 0（或更激进的 o.done == 0）并不能与 o.m.Lock() 或 o.m.Unlock() 构成 happens-before 关系，也就没法保证外面能读取到被修改后的值。
   同样，因为第一条的原因，在 x86 上，外面是可以立刻观测到值的变化的。即使没有观测到，doSlow() 中还有二次检查，并不会导致 f() 被执行多次。但出于兼容性考虑，不使用原子操作时，可能会造成观测不到 o.done 的写入而一直进入 doSlow()，反而更加影响性能。而且这个原子操作只需要执行一次，并不会影响后续调用的性能。
   

• 不允许引入源代码中不存在的写入。
  
• 不允许将无数据竞争的程序引入数据竞争：
  
  • 不能将写操作移出它所出现的条件语句。例如下列程序：
    

    *p = 1
    if cond {
    	*p = 2
    }

    不能改写成：
    

    *p = 2
    if !cond {
    	*p = 1
    }

  • 不假设循环终止。例如下列程序，不能把对 *p 或 *q 的访问提到循环之前：
    

    n := 0
    for e := list; e != nil; e = e.next {
    	n++
    }
    i := *p
    *q = 1

  • 不假设被调用的函数总是返回或者没有同步操作。例如下列程序，不能把对 *p 或 *q 的访问提到函数调用之前:
    

    f()
    i := *p
    *q = 1

• 不允许单次读操作观测到多个值。这意味着不从共享内存中重新加载局部变量，例如：
  

  i := *p
  if i < 0 || i >= len(funcs) {
  	panic("invalid function index")
  }
  ... complex code ...
  // 此处编译器不能重新加载 i = *p
  funcs[i]()

• 不允许单次写操作写入多个值。这意味着不能将变量将要被写入内存作为临时存储，例如下列程序：
  

  *p = i + *p/2

  不能被改写成：
  

  *p /= 2
  *p += i