优雅解决传递通道和共享内存导致的数据竞争

在 Go 语言中，混合使用消息传递（通道）和共享内存可能会导致数据竞争。文章分析了两个函数（start 和 wait）中数据竞争的示例，并提出了一种使用上下文来处理竞争的解决方案。但是，该解决方案仍然存在数据竞争的可能性。更优雅的解决方法是使用互斥体来保护共享内存，确保对共享数据的访问是排他性的，从而消除数据竞争。

这是 go 中数据竞争模式的一个案例

消息传递（通道）和共享内存的混合使用使代码变得复杂并且容易受到数据竞争的影响

func (f *future) start() {
    go func() {
        resp, err := f.f()
        f.resp = resp
        f.err = err        // data race
        f.ch <- struct{}{} // may block forever
    }()
}

func (f *future) wait(ctx context.context) error {
    select {
    case <-f.ch:
        return nil
    case <-ctx.done():
        f.err = ctx.err() // data race
        return ctx.err()
    }
}

这是 f.err 的一场数据竞赛，可以在 start 和 wait 中访问。

另一个问题是，当 ctx.done() 发生在 f.ch <- struct{}{} 之前时，f.ch <- struct{}{} 可能会永远阻塞。

在 golang 中处理它的优雅方式是什么？

我首先想到的想法如下，为 start 函数添加上下文

func (f *Future) Wait(ctx context.Context) error {
    select {
    case <-f.ch:
        return nil
    case <-ctx.Done():
        f.err = ctx.Err()
        return ctx.Err()
    }
}

func (f *Future) StartWithContext(ctx context.Context) {
    go func() {
        resp, err := f.f()

        select {
        case <-ctx.Done():
            return
        default:
            f.resp = resp
            f.err = err
            f.ch <- struct{}{}
        }
    }()
}

我们想知道我的解决方案中是否缺少某些内容？或者这个问题有更好的解决方案吗？

正确答案

第二个代码片段中仍然存在数据争用。 startwithcontext 有可能首先落入 default 情况，然后 wait 落入 ctx.done() 情况。

您遇到了共享内存问题，最明显的处理方法是使用互斥体。另请注意，您正在使用 f.ch 作为完成通道，因此：

type Future struct {
   sync.Mutex
   ...
}


func (f *Future) Start() {
    go func() {
        resp, err := f.f()
        f.Lock()
        f.resp = resp
        f.err = err 
        f.Unlock()
        close(f.ch)
    }()
}

func (f *Future) Wait(ctx context.Context) error {
    select {
    case <-f.ch:
        return nil
    case <-ctx.Done():
        f.Lock()
        f.err = ctx.Err()
        f.Unlock()
        return ctx.Err()
    }
}

本篇关于《优雅解决传递通道和共享内存导致的数据竞争》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！