Atomic Memory Operations

Atomic memory operations provide the low-level foundation necessary to implement other synchronization primitives. In general, you can replace all atomic operations of a concurrent algorithm with mutexes and channels. Nevertheless, they are interesting and sometimes confusing constructs, and you should know how they work. If you use them carefully, they can become good tools for code optimization without increasing complexity.

In this chapter, we will explore the following topics:

• Memory guarantees of atomic memory operations
• The compare-and-swap operation
• Practical uses of atomics, including counters, heartbeats/progress meters, cancellations, and detecting change

Technical Requirements

The source code for this particular chapter is available on GitHub at https://github.com/PacktPublishing/Effective-Concurrency-in-Go/tree/main/chapter9.

Memory guarantees

Why do we need separate functions for atomic memory operations? If we write to a variable whose size is less or equal to the machine word size (which is what the int type is defined to be), such as a=1, wouldn’t that be atomic? The Go memory model actually guarantees that the write operation will be atomic; however, it does not guarantee when other goroutines will see the effects of that write operation, if ever. Let’s try to dissect what this statement means. The first part simply says that if you write to a shared memory location that is the same size as a machine word (i.e., int) from one goroutine and read it from another, you will not observe some random value even if there is a race. The memory model guarantees that you will only observe the value before the write operation, or the value after it (this is not true for all languages.) This also means that if the write operation is larger than the machine word size, then a goroutine reading this...

Compare and swap

Any time you test for a condition and act based on the result, you can create a race condition. For example, the following function does not prevent mutual exclusion, despite the use of atomics:

var locked sync.Bool
func wrongCriticalSectionExample() {
     if !locked.Load() {
          // Another goroutine may lock it now!
          locked.Store(true)
          defer locked.Store(false)
          // This goroutine enters critical section
          // but so can another goroutine
     }
}

The function starts by testing whether the atomic locked value is false. Two goroutines can execute this statement simultaneously, and seeing that it is false, both can enter the...

Practical uses of atomics

Here are a few examples of using atomics. These are simple race-free uses of atomics in different scenarios.

Counters

Atomics can be used as efficient concurrency-safe counters. The following program creates many goroutines, each of which will add 1 to the shared counter. Another goroutine loops until the counter reaches 10000. Because of the use of atomics here, this program is race-free, and it will always terminate by eventually printing 10000:

var count int64
func main() {
     for i := 0; i < 10000; i++ {
          go func() {
               atomic.AddInt64(&count, 1)
               }()
          }
     for {
     &...

Summary

In conclusion, you do not need atomics to implement correct concurrent algorithms. However, they can be nice to have if you identify a concurrency bottleneck. You can replace some simple mutex-protected updates (such as counters) with atomics, provided you also use atomic reads to read them. You can use CAS operations to detect concurrent modifications, but also note that few concurrent algorithms need that.

In the next chapter, we will look at how we can diagnose problems and troubleshoot them in concurrent programs.