对golang sync.once 实现的思考

zhubaba · · 417 次点击 · · 开始浏览

这是一个创建于的文章，其中的信息可能已经有所发展或是发生改变。

源代码分析

sync.Once的源码很精简，但是有一行原子操作的代码却让我产生了疑惑。

在提出疑惑前，我们先分析下其实现的源代码。

我先添加一些基本的注释

// 去掉了源代码里面的注释
// Once is an object that will perform exactly one action.
type Once struct {
    done uint32
    m    Mutex
}

func (o *Once) Do(f func()) {
    // fast path， 
    // o.done=0代表还没有执行过f函数
    // 原子变量，保证cache coherence
    if atomic.LoadUint32(&o.done) == 0 {
        // 如果没有执行过f函数，则进入slow path
        o.doSlow(f)
    }
}

func (o *Once) doSlow(f func()) {
    // 进入临界区
    o.m.Lock()
    defer o.m.Unlock()
    // double check，如果还是没有goroutine执行 f 函数
    // 这里无需原子操作，是因为 o.m.Lock()本身是 acquire语义的，
    if o.done == 0 {
        // 当执行完f()后，将o.done设置为1
        defer atomic.StoreUint32(&o.done, 1)
        f()
    }
}

问题

当我看源码时的第一感觉就觉得defer atomic.StoreUint32(&o.done, 1)有点多余，貌似可以直接替换为o.done=1。
因为defer o.m.Unlock() 是有release语义的。能保证cache coherence。

看上去确实有道理，但是又觉得肯定没有这么简单。
于是冷静思想。。。。

答案

不要轻易查看答案，先请自己思考，

先不要看答案

结论

defer atomic.StoreUint32(&o.done, 1) 不能替换为o.done=1。

分析

因为虽然defer o.m.Unlock()是release语义，能保证cache coherence；但是要考虑到 m.done和 f()的 synchronizes-with关系。

假如，有段代码

sync.Do(initOnce)

func initOnce() {
    value=1
}

这个时候的 sync.Do中，几个变量的操作顺序是

value=1
o.done = 1
o.m.Unlock()

那么问题就出现了，value=1和o.done=1在强内存序CPU下线程内是不会乱序的，但是并不能保证value=1和o.done=1在线程间的synchronizes-with关系。
所以就会导致问题的发生：

当线程A在CPU1执行完 value=1 ，再执行o.done=1，注意，假设此时还没有执行o.m.Unlock(), 这个时候在CPU的cache中value和o.done都是1了。
但是在其他CPU（如CPU2）的cache里却不一定了，有可能是value=0而o.done=1，那么就会导致线程B在CPU2上执行sync.Do(initOnce)时，会因为o.done=1不会再执行initOnce了，线程B就会认为已经执行过了，也就以为value=1了，而实际value=0，这就是为什么o.done=1需要使用原子操作了。