4 ms·
I believe that's exactly what they were doing with the StorePointer/LoadPointer primitives. However it is generally agreed in the Go community that the sync/ato
by spyspy 11y ago
I believe that's exactly what they were doing with the StorePointer/LoadPointer primitives. However it is generally agreed in the Go community that the sync/atomic is to be avoided in favor of the sync/mutex for this type of problem. The RWMutex is designed for a 1 writer/N readers scenario. The code is more readable and you don't offload any work to the GC.
- pcwalton 11y ago> However it is generally agreed in the Go community that the sync/atomic is to be avoided in favor of the sync/mutex for this type of problem. Why? Concurrent data structures are extremely useful. > The code is more readable and you don't offload any work to the GC. You shouldn't write concurrent data structures yourself; you should use a library. And the amount of time spent in the GC for this is going to be negligible assuming writes are infrequent compared to reads. It's rare in a GC'd language that your write operation won't be creating garbage somewhere along the way, so it ends up being amortized.