Demystifying Go (Golang), Google’s Programming Language: Race Conditions and the Sync Package

Introduction

Today, we’ll talk about one of the biggest villains in concurrent programming: the dreaded race condition. This problem sends shivers down the spines of developers worldwide, but don’t worry, dear Gopher! We’re going to explore how Go’s sync package can help us solve this issue and ensure our code’s integrity. Ready to break it down bit by bit? Let’s dive in!

Race Condition

Have you ever heard of a race condition? In short, it’s a common concurrency bug that happens when two or more threads try to access and modify the same resource at the same time, leading to inconsistencies and unexpected results. In Go, when we call goroutines asynchronously, this can happen. To illustrate, check out the example below.

Here, we create a type called Connector to simulate a connection resource that should only be initialized once, following the singleton pattern. The Connect function, assigned to Connector, prints the connection attempt number, while the NewConnector function returns a new Connector with the attempt number set. The GetConnector function checks if the connector is null; if it is, it creates a new connector. Otherwise, it returns the existing connector. This seems like a solid singleton implementation, but see what happens when we call GetConnector and then Connect in 20 simultaneous goroutines.

Notice that even with the validation to check if the connector is null, two connectors were created: one on attempt 8 and another on attempt 19, with the last one created taking precedence. This is the result of a race condition, where two goroutines accessed the GetConnector function at the same time, leading to the creation of multiple connectors.

This code might seem to work fine in some executions, but be careful! At some point, it will fail, compromising the application’s integrity. Check out the example below, where everything appears normal.

Now you might be wondering: how can I tell if my code is subject to a race condition? There are a few ways, but the most effective is by running Go’s unit tests. In the example below, we created a main_test.go file and ran tests on the same code used in main. To run the tests, simply use the command go test, which will automatically detect all the test files in the project.

“But... everything seems fine!” you might think. True, but here’s the catch: Go allows you to run tests with the --race parameter, which enables race condition detection in the code. Let’s see what happens when we use it:

Notice that it reports race detected during execution. Further up, the "WARNING: DATA RACE" message indicates that our code is prone to inconsistencies. The --race tool helps detect these critical spots and is a great ally in safe development.

The importance of well-designed unit tests in our applications is clear, right?

Sync Package

So, how do we fix this? Who can save us now? Don’t worry, Gopher! Go offers several solutions for concurrency, including the sync package and atomic variables (which we’ll cover in another post). Today, we’ll focus on using Mutex from the sync package.

The Mutex implements the concept of mutual exclusion, providing Lock and Unlock methods that allow you to protect a code block, ensuring that only one goroutine can access it at a time. We’ll apply this protection to our code by modifying the GetConnector function. First, we create a sync.Mutex variable just above the function, and then we wrap the code block that initializes our Connector with mu.Lock() and mu.Unlock() to lock and unlock access to the code block.

To make sure the issue is resolved, let’s run the test again with the --race parameter. Here’s what we get:

Voilà! Now we have thread-safe code, free from race conditions.

Conclusion

Race conditions can be tricky, but with sync.Mutex and a touch of attention, we can protect our code from them. There are still other ways to tackle concurrency issues, which we’ll cover in upcoming posts. So, keep your IDE open and ready—this is just the beginning! Let’s keep exploring the amazing world of Go and its concurrency tools. Until next time, Gopher!