Data Race vs. Race Condition

Key Differences for Developers

📅 Last updated: April 18, 2026

☕ Welcome to The Coder Cafe! Developers frequently mix up data races and race conditions. Today we’ll explore both: what makes them different, why fixing one doesn’t fix the other, and how to spot each in your own code. We’ll also wrap up with an FAQ covering common developer questions. Get cozy, grab a coffee, and let’s begin!

Data Race vs. Race Condition: What Every Developer Should Know

• A data race occurs when two or more threads simultaneously access the same memory location, and at least one of these accesses is a write operation.

• A race condition refers to any situation where the outcome depends on the timing of events that can’t be controlled, such as which thread runs first.

Consider the following code:

// Thread 1 code
coffee.price = 10

// Thread 2 code
print(coffee.price)

If the two threads can run concurrently and we can’t control which thread executes first, this code produces a data race. Indeed, thread 1 writes to the price variable, whereas thread 2 reads it. The value printed by thread 2 is unpredictable—it could be 10 if thread 1 executes first or the initial price if thread 1 executes afterward.

Data races can result in corrupted data, system instability, and are often a source of subtle and hard-to-track bugs. To avoid these, we should use synchronization mechanisms. For example, with a mutex:

// Thread 1 code
mutex.Lock()
coffee.price = 10
mutex.Unlock()

// Thread 2 code
mutex.Lock()
print(coffee.price)
mutex.Unlock()

This code resolves the data race by using a mutex to ensure that only one thread accesses price at a time. Yet, is the outcome deterministic? Still not. Depending on which thread executes first, thread 2 will still print different results. In this example, we can’t control the sequence between thread 1 and thread 2; therefore, it’s a race condition.

Not all race conditions are problematic. For example, a Twitter post showing 605 likes instead of 606 for a few seconds is a harmless race condition. However, if our bank application shows an outdated account balance after a transaction, that’s more impactful.

All data races are race conditions, yet not all race conditions are data races. It’s important to understand that a data-race-free application doesn’t necessarily guarantee deterministic results. Indeed, an application can be free of data races but still exhibit race conditions due to factors like thread execution order or database call durations.

FAQ

Can we have a race condition without a data race?

Yes, and this is the case that most developers underestimate. Our mutex example above is exactly that: every memory access is properly synchronized, but the program’s outcome still depends on which thread runs first. Classic examples include time-of-check to time-of-use (TOCTOU) bugs, check-then-act patterns on a map, and ordering bugs between distributed services. None of these involves unsynchronized memory access, yet all are race conditions.

Can we have a data race without a race condition?

Technically, a data race is a race condition by definition. Indeed, the outcome depends on timing, because the read and write aren’t ordered. So no, we cannot have a data race that is not also a race condition. This is why the one-way inclusion holds: data races ⊂ race conditions.

That said, the relationship is stricter in languages like C and C++, where a data race is undefined behavior: the compiler is free to reorder, eliminate, or transform the access in ways that have nothing to do with thread scheduling. In those languages, a data race is not merely a timing-dependent race condition but an ill-formed program, regardless of what the execution actually produces.

Is every race condition a bug?

No. A race condition is only a bug if the possible outcomes include one we don’t want. If a background job updates a “last seen” timestamp and two threads race to write it, the result is still a valid timestamp, no harm done (assuming the write itself is atomic; a torn 64-bit write on a 32-bit platform would be a data race, not just a race condition). The same pattern on a bank balance is catastrophic. The bug is in the business invariant, not in the race itself.

Does a mutex prevent race conditions?

A mutex prevents data races, not all race conditions. It guarantees that only one thread is inside the critical section at a time, but it does not dictate which thread gets there first, or whether the overall sequence of operations across your system respects your business logic. To eliminate the higher-level race condition, we usually need something more: a transaction, an idempotent operation, a version number, or a redesign that removes the timing assumption altogether.

Are atomic operations enough to prevent data races?

Atomic operations prevent the data race on a single variable: reads and writes are indivisible, and (depending on the memory ordering used) the memory model gives you ordering guarantees. For example, Go’s sync/atomic provides sequentially consistent ordering by default, but C++ and Rust let you select weaker orderings (memory_order_relaxed, Ordering::Relaxed) that trade ordering for performance. Atomicity and ordering are separate guarantees.

However, composing multiple atomics does not make a compound operation atomic. The following example is still racy, even though each individual call is atomic:

if counter.Load() == 0 {
  counter.Store(1)
}

For compound operations on a single variable, we can use a compare-and-swap (CAS) loop. For compound operations spanning multiple variables, CAS alone is not enough; we need a mutex, a transactional memory primitive, or a carefully designed lock-free data structure.

How do I detect data races?

Most modern ecosystems ship a race detector. For example:

• In Go, go test -race and go run -race instrument memory accesses and flag unsynchronized ones.

• In C and C++, ThreadSanitizer (-fsanitize=thread) does the same.

• For native code on Linux, Valgrind’s Helgrind tool works without requiring recompilation.

• Java’s jcstress is a related but different tool: rather than instrumenting memory accesses, it stress-tests concurrent classes under heavy contention to expose non-deterministic outcomes, useful for finding bugs that escape static analysis, though not a drop-in equivalent of TSan.

These detectors only find races that actually occur during execution, so code coverage matters: a race on a cold code path may ship to production undetected.

How do I detect race conditions?

This is harder. Since race conditions can live entirely above the memory model, sanitizers won’t catch them. The tools that help are more about design discipline: code review focused on invariants, model checking (TLA+, Alloy) for distributed systems, property-based testing with randomized schedules, and chaos testing in staging environments. A good heuristic is to ask, for every critical operation: “What would happen if this ran twice? Out of order? Interleaved with its sibling?”

Resources

More From the Programming Category

• Concurrency vs. Parallelism

• Mutex vs. Semaphore

• Coroutines

---

❤️ If you enjoyed this post, please hit the like button.