Goroutines 和 C 线程之间的原子栅栏并发 - 语义是什么？

如何解决Goroutines 和 C 线程之间的原子栅栏并发 - 语义是什么？

我想知道是否可以明确协调 goroutines 和 C 线程之间的原子操作并发。

这里的用例涉及一个 C 语言的音频处理库，它创建一个操作系统线程，并定期调用用户提供的回调来检索音频数据。这必须几乎实时发生，所以我不想招致 cgo 调用、堆栈交换和 Go-land 并发的开销。环形缓冲区一般可以解决这个问题，其中一个线程写入缓冲区，另一个读取，并使用内存栅栏执行同步。

然而，目前 Go 中原子操作的内存语义似乎在文档中完全没有定义，因此对于这个目的完全没有用，可能还有很多其他的......（https://golang.org/pkg/sync/atomic/ 只是说无益“原子”，见 https://github.com/golang/go/issues/5045)

但是 - 它必须以某种方式工作，即使没有记录在案。怎么样？

请注意，我并不是在询问我所描述的问题的解决方案。我不是在问环形缓冲区是否是正确的选择，或者我是否应该“通过共享进行通信”或其他什么。我问的是 Go 中当前实现的原子操作的内存顺序语义（例如，最新的发布版本 - 1.16.5 的具体性）。

特别是，这里是一个示例程序，它设置了与我的实际用例中发生的情况类似的情况：

package main

/*

   #include <pthread.h>
   #include <malloc.h>

   typedef struct {
      int fence_0;
      char *data;
   } shared_data;

   shared_data *make_shared_data() {
      shared_data *sd = calloc(sizeof(shared_data),1);
      sd->data = calloc(1024,1);
      sd->data[0] = 17;
      return sd;
   }

   void *get_shared_data_ptr(shared_data *sd) {
      return sd->data;
   }

   int read_data_in_pthread(shared_data *sd) {
      int l;
      __atomic_load(&sd->fence_0,&l,__ATOMIC_ACQUIRE);
      if (l < 2) return 0;
      return sd->data[0] + sd->data[1023]; 
   }

*/
import "C"
import (
   "fmt"
   "runtime"
   "reflect"
   "unsafe"
   "sync/atomic"
)

func main() {

   // Prevent thread/cache switching (to avoid asking a third,unimportant question and allow the below "naughty")
   runtime.LockOSThread()

   // Allocate a C-owned structure.
   csd := C.make_shared_data()

   // This is just an expedient for the sake of this example,I'm aware it's naughty/bad,etc.
   ptr := (*byte)(C.get_shared_data_ptr(csd))
   arrptr := &reflect.SliceHeader{Data: uintptr(unsafe.Pointer(ptr)),Len: 1024,Cap: 1024}
   arr := *(*[]byte)(unsafe.Pointer(arrptr))

   fmt.Printf("%d\n",arr[0])
   done := make(chan bool)

   // Repeatedly execute a reader function in a cgo thread which will output zero if first fence is not 2
   // and output the sum of the first and last data points if it is.
   go func(){
         var s uint8
         s = 0
         for s == 0 {
            s = uint8(C.read_data_in_pthread(csd))
         }
         fmt.Printf("finished: %d\n",s)
         done <- true
      }()

   go func(){
         atomic.StoreInt32((*int32)(&csd.fence_0),1)
         for i := 0; i < 1024; i++ {
            arr[i] = 255
         }
         atomic.StoreInt32((*int32)(&csd.fence_0),2)
   }()

   <-done
}

问题是：(a) 这个程序的输出可以是 17 吗？ (b) 如果不是，这个程序的输出必须总是254，还是可能是255？

如果 Go 原子存储使用类似于 gcc 的 ATOMIC_SEQ_CST 的内存模型，则内存栅栏是顺序的，我们将始终看到 254。这似乎是一个明智的默认设置。但是，这一定是真的吗？

否则，我的程序将不可移植并产生错误。所以，我想确定。

（是的，我知道上面的测试用例绝对是完全不可移植的/只能在 GNU/Linux 上运行...实际有问题的库实际上是可移植的。）

解决方法

在 Go memory model 和 C 和 C++ 中可用的（多个）内存模型之间存在某种阻抗不匹配（参见关于 C 内存顺序选项的 cppreference.com，并注意 { {3}}）。至少在理论上，这会给实现者带来一些大麻烦：通过 cgo 调用 C 代码的传入和传出，如果例如 Go 系统使用某种整体或部分存储订单模型和 C 系统使用宽松的内存模型。

在实践中，例如，每个实现都将努力为 atomic-load-32 和 atomic-store-32 使用相同类型的同步。但是：

[剪辑]

但是 - 它必须以某种方式工作，即使没有记录在案。怎么样？

您将不得不一次一个地查看每个实现，因为“如何”可能（至少可能）每次都不同。因此，找出您的系统在其 PowerPC 实现上使用什么，找出您的系统在其 ARM 实现上使用什么，等等。您会希望低级 Go 例程是特定于实现的，选择与低级 C 例程一起使用。

语言本身没有定义任何原子操作。但是，sync/atomic 包可以。您链接的问题以“doc:”为前缀，这意味着他们只是在讨论如何改进围绕 atomic 与 Go 内存模型交互的文档。该软件包仍然有效。如所述，其中的操作是原子的。任何已知的异常都列在“错误”部分：https://golang.org/pkg/sync/atomic/#pkg-note-BUG

Goroutines 和 C 线程之间的原子栅栏并发 - 语义是什么？

如何解决Goroutines 和 C 线程之间的原子栅栏并发 - 语义是什么？

解决方法

相关推荐