Why does `sync.Once` utilize atomic operations like `atomic.StoreUint32` instead of a simple assignment?

Why Use Atomic Operations in Sync.Once Instead of Normal Assignment?

The Go concurrency model requires the use of atomic operations even if underlying machine primitives are atomic, ensuring correctness across all supported architectures.

In sync.Once, the atomic.StoreUint32 operation is used to set the done flag after the function f has been executed. This ensures that other goroutines observe the effects of f before the done flag is set to 1.

Advantages of Atomic Operations:

1. Safety: Atomic operations guarantee that the write is performed as a single uninterruptible event, preventing data corruption.
2. Optimization: In the fast path, the done flag is accessed without acquiring a lock. Atomic operations allow this optimization while still maintaining safety.

Differences Between Atomic Operations and Normal Assignments:

1. Guarantees: Atomic operations provide stronger guarantees than normal assignments. They ensure that other threads will observe the write after it has been performed.
2. Performance: Atomic operations can be more efficient than acquiring a lock and performing a normal assignment.

Why Delay atomic.StoreUint32 in doSlow?

The atomic.StoreUint32 operation is delayed in doSlow to ensure that f has been executed before the done flag is set. This is because f may be a long-running function, and setting the done flag too early could prevent other goroutines from accessing necessary resources.

In summary, sync.Once uses atomic.StoreUint32 instead of o.done = 1 to ensure safety, optimize performance, and maintain correctness across all supported architectures with weak memory models.

The above is the detailed content of Why does `sync.Once` utilize atomic operations like `atomic.StoreUint32` instead of a simple assignment?. For more information, please follow other related articles on the PHP Chinese website!