Race conditions in Golang

Ercan Gerçek
Jun 17 · 5 min read
I like Formula1, so here is a photo of a race car. Photo by Paul Cuad on Unsplash

Writing multi-threaded applications is a non-trivial job and requires planning before implementation. If you were using a single-threaded language such as JavaScript, understanding the basics is quite essential. However, if you are familiar with low-level languages like C or C++, the concepts are similar. In this blog post, I want to explain how race condition occurs and how to synchronize data access using Golang.

What is a race condition?

A race condition occurs when multiple threads try to access and modify the same data (memory address). E.g., if one thread tries to increase an integer and another thread tries to read it, this will cause a race condition. On the other hand, there won't be a race condition, if the variable is read-only. In golang, threads are created implicitly when Goroutines are used.

Let’s try to create a race condition. The easiest way to do it is by using multiple gouroutines, and at least one of the goroutines must be writing to a shared variable.

Following code demonstrates a simple way to create a race condition.

  • A goroutine reads the variable named “sharedInt”

If you run this code, this will not result in a crash, but sometimes the reader goroutine will access an outdated copy of “sharedInt”. If you run the code with the built-in race condition checker, the go compiler will complain about the problem.

go run -race .

A small note about the Golang race condition checker: if your code occasionally accesses shared variables, it might not be able to detect the race condition. To detect it, the code should run in heavy load, and race conditions must be occurring.

You can see the output of the race condition checker. It complains about unsynchronized data access.

How can we solve this problem? If the shared data is a single variable, we can use counters provided in the sync/atomic pack. In the following example, instead of accessing the shared variable directly, we can use the atomic.LoadInt64()/atomic.AddInt64() pair to access it. The race condition checker will not complain about the unsynchronized data access anymore.

This solves our problem when using primitive variables, but we need to access multiple variables and work with complex data structures in many cases. In these cases, it makes sense to control the access by using mutexes.

The following example demonstrates unsynchronized access to a map. When using complex data structures, race conditions could result in a crash. Therefore, if we run this example without race check enabled, the go runtime will complain about the concurrent access, and the process will exit.

fatal error: concurrent map read and map write

It is possible to fix this problem by controlling access to the critical section. In this example, the critical section is where we read and write to the “sharedMap”. In the example below, we call mutex.Lock() and mutex.Unlock() pair to control the access.

How does mutex work?

  • Mutex is created in an unlocked state.

For example, we can control access to the critical section by using a mutex. I added a context to cancel the goroutines after working for 2 seconds. You can ignore the code related to context if you are not familiar with it.

If we run the example code, go runtime will not complain about concurrent map read and map write anymore because only one goroutine can access the critical section at a time.

In the example, I used 15 reader goroutines and a single writer goroutine. The writer updates the “sharedMap” every 100 milliseconds. It could be better to use RWMutex (reader/writer mutual exclusion lock) in cases like this. It is similar to a mutex, but it also has another locking mechanism to let multiple readers access the critical section when it is safe. This could perform better when writes are rare, and reads are more common.

How does RWMutex works?

  • In simpler terms, multiple readers can access the critical section if there are no writers. If a writer tries to access the critical section, all reads are blocked. This is more efficient when the writes are rare, and the reads are common.

Mutex vs RWMutex Performance

I ran the examples five times and compared the averages. As a result, RWMutex performed 14.35% more read operations. But please keep in mind that this example is highly biased as there are 15 reader goroutines and a single writer goroutine.


In this blog post, I tried to go over the basics of unsynchronized data access, which results in race conditions. If you are not familiar with multi-threaded programming, it is easy to overlook this and run into problems.

In my personal experience, I would prefer making every goroutine/thread use its own variables in an isolated context and propagating the changes to an aggregator by using channels. Usually, it is easier to design single-threaded components that communicate over channels or queues. However, this approach is not suitable in every case, and mutexes can come in handy.

Thanks for reading. If you have any feedback or found a mistake, please let me know.

Trendyol Tech

Trendyol Tech Team

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Start a blog

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store