XQA
Back to C Programming
2026-01-279 min read

Atomic operations

Learn Atomic operations step by step with clear examples and exercises.

Why This Matters

Atomic operations are an essential aspect of concurrent programming in C, ensuring that multiple threads can safely access and manipulate shared data without causing inconsistencies or conflicts. In this lesson, we will delve deeper into the world of atomic operations, learning about their importance, how they work, common pitfalls to avoid, and more.

Prerequisites

To fully grasp atomic operations, you should have a solid understanding of:

  1. Basic C programming concepts, including variables, functions, pointers, and data structures like arrays and linked lists.
  2. Threading basics, such as creating and managing threads, and synchronization mechanisms.
  3. Understanding the issues that can arise in concurrent programming, such as race conditions and deadlocks.
  4. Familiarity with memory management concepts, such as volatile variables and memory barriers.

Core Concept

Atomic operations are special functions provided by the `` header that perform an operation on a single memory location in a thread-safe manner. These operations ensure that no other thread can interfere with the operation while it's being executed, preventing data races and ensuring the integrity of shared data.

Atomic Types

The most common atomic types in C are:

  • _Atomic int: an atomic integer.
  • _Atomic unsigned int: an atomic unsigned integer.
  • _Atomic long: an atomic long integer.
  • _Atomic unsigned long: an atomic unsigned long integer.
  • atomic_flag: an atomic flag that can be set or cleared atomically.

Atomic Operations

Here are some of the most commonly used atomic operations in C, along with their descriptions and examples:

  1. atomic_init(atomic*, int): Initializes an atomic variable with a given value.
_Atomic int counter = ATOMIC_VAR_INIT(0);
  1. atomic_store(atomic*, int): Stores a value into an atomic variable.
atomic_store(&counter, new_value);
  1. atomic_load(atomic*): Loads the value of an atomic variable.
int current_value = atomic_load(&counter);
  1. atomic_exchange(atomic*, int): Atomically exchanges the current value of an atomic variable with a new value and returns the previous value.
int old_value = atomic_exchange(&counter, new_value);
  1. atomic_compare_exchange_strong(atomic*, int*, int): Compares and exchange operation that atomically compares the current value of an atomic variable with a expected value, and if they match, stores a new value into the atomic variable.
int success = atomic_compare_exchange_strong(&counter, &expected_value, new_value);
  1. atomic_fetch_add(atomic*, int): Atomically adds a given value to an atomic variable and returns the previous value.
int old_value = atomic_fetch_add(&counter, increment);
  1. atomic_fetch_sub(atomic*, int): Atomically subtracts a given value from an atomic variable and returns the previous value.
int old_value = atomic_fetch_sub(&counter, decrement);
  1. atomic_flag_init(atomic_flag*, int): Initializes an atomic flag with a given state (0 or 1).
atomic_flag flag = ATOMIC_FLAG_INIT;
  1. atomic_flag_test_and_set(atomic_flag*): Atomically sets an atomic flag and returns its previous state.
int old_state = atomic_flag_test_and_set(&flag);
  1. atomic_flag_clear(atomic_flag*): Atomically clears an atomic flag.
atomic_flag_clear(&flag);

Memory Ordering

Atomic operations in C support various memory ordering constraints, which determine the order in which memory accesses happen relative to each other. The most common memory orders are:

  • memory_order_relaxed (default): No ordering constraints.
  • memory_order_consume: Acquires a release semantic from the given memory location.
  • memory_order_acquire: Acquires a sequential acquire semantic from the given memory location.
  • memory_order_release: Releases a sequential release semantic to the given memory location.
  • memory_order_seq_cst: Strictly enforces a sequential consistent ordering, which is the strongest memory order.

Worked Example

Let's consider a more complex example of using atomic operations to safely implement a concurrent counter that supports both increment and decrement operations:

#include <stdio.h>
#include <stdatomic.h>
#include <pthread.h>

_Atomic long counter = ATOMIC_VAR_INIT(0);

void* increment(void* arg) {
for (int i = 0; i < 1000000; ++i) {
atomic_fetch_add(&counter, 1);
}
return NULL;
}

void* decrement(void* arg) {
for (int i = 0; i < 1000000; ++i) {
atomic_fetch_sub(&counter, 1);
}
return NULL;
}

int main() {
pthread_t threads[2];

pthread_create(&threads[0], NULL, increment, NULL);
pthread_create(&threads[1], NULL, decrement, NULL);

// Wait for both threads to finish
pthread_join(threads[0], NULL);
pthread_join(threads[1], NULL);

printf("Counter: %ld\n", counter);
return 0;
}

In this example, we define a shared atomic long integer counter and two threads that increment and decrement it one million times each. By using atomic_fetch_add for increments and atomic_fetch_sub for decrements, we ensure that the operations are performed atomically, preventing data races.

Common Mistakes

  1. Forgetting to initialize atomic variables: Always use atomic_init to initialize atomic variables before using them.
  2. Ignoring memory ordering constraints: Incorrect memory ordering can lead to data inconsistencies and hard-to-debug issues. Make sure to use the appropriate memory order for each operation.
  3. Misusing atomic operations: Atomic operations should be used only when necessary, as they may introduce performance overhead.
  4. Mixing atomic and non-atomic accesses: Mixing atomic and non-atomic accesses to the same variable can lead to data inconsistencies. Make sure to use atomic operations consistently for shared variables.
  5. Not using atomic flags properly: Atomic flags should be used carefully, as they can easily lead to deadlocks if not released correctly.
  6. Incorrect usage of memory orderings: Using the wrong memory ordering can lead to unexpected behavior and data inconsistencies. Make sure you understand these semantics before using an atomic operation.
  7. Not testing for errors: Always check the return value of atomic functions to ensure they succeeded and handle any potential errors appropriately.
  8. Overusing atomic operations: Atomic operations should be used judiciously, as they can introduce performance overhead. Use them only when necessary to prevent data races.
  9. Not understanding the semantics of atomic operations: Each atomic operation has a specific set of semantics that determine its behavior in different scenarios. Make sure you understand these semantics before using an atomic operation.
  10. Not considering memory barriers: Memory barriers are used to ensure that certain memory accesses happen in a specific order, which can be important for correctness and performance.
  11. Incorrect use of volatile variables: Volatile variables should only be used when necessary, as they can prevent optimizations that might otherwise improve performance.

Practice Questions

  1. Write a program that atomically increments a shared counter by 2 using atomic_fetch_add.
  2. Implement an atomic swap function using atomic_compare_exchange_strong.
  3. Write a simple producer-consumer example using atomic operations to safely share a buffer between two threads.
  4. Explain the difference between memory_order_relaxed and memory_order_seq_cst.
  5. What is the performance overhead of using atomic operations, and how can it be minimized?
  6. How does the choice of memory ordering affect the behavior of atomic operations in a concurrent program?
  7. When should you use an atomic flag instead of a mutex, and when should you use a mutex instead of an atomic flag?
  8. What are some common patterns for using atomic operations to ensure safe access to shared data in concurrent programs?
  9. How can you debug issues related to atomic operations in your code?
  10. What are the potential consequences of not using atomic operations when working with shared data in a concurrent program?
  11. Explain the role of memory barriers and how they are used in concurrent programming.
  12. Discuss the use of volatile variables in C and their implications for concurrent programming.

FAQ

  1. Why are atomic operations necessary in concurrent programming?

Atomic operations ensure that shared data is accessed and manipulated safely by multiple threads, preventing data races and inconsistencies.

  1. What is the difference between atomic_fetch_add and atomic_add?

atomic_fetch_add returns the previous value of the atomic variable after adding the given value, while atomic_add only adds the value without returning the previous value.

  1. Can I use atomic operations with non-atomic variables?

Yes, but mixing atomic and non-atomic accesses to the same variable can lead to data inconsistencies. It's best to use atomic operations consistently for shared variables.

  1. What is the performance overhead of using atomic operations?

Atomic operations may introduce some performance overhead due to their thread-safe nature, but modern processors have optimized support for atomic operations, so the overhead is usually minimal in practice. However, excessive use of atomic operations can lead to significant performance degradation.

  1. How does the choice of memory ordering affect the behavior of atomic operations in a concurrent program?

The choice of memory ordering determines the order in which memory accesses happen relative to each other. Different memory orders have different guarantees and implications for the behavior of atomic operations in a concurrent program. For example, memory_order_seq_cst provides the strongest consistency guarantees but may introduce more overhead compared to memory_order_relaxed.

  1. When should you use an atomic flag instead of a mutex, and when should you use a mutex instead of an atomic flag?

Atomic flags are useful for simple synchronization tasks where a single boolean value is sufficient, such as signaling the availability of a resource or indicating that a critical section has been entered. Mutexes are more appropriate for more complex synchronization scenarios, such as protecting shared data structures from simultaneous access by multiple threads.

  1. What are some common patterns for using atomic operations to ensure safe access to shared data in concurrent programs?

Common patterns include using atomic counters to manage shared resources, using atomic flags to signal the availability of a resource or indicate that a critical section has been entered, and using atomic compare-and-swap (CAS) operations to implement lock-free data structures.

  1. How can you debug issues related to atomic operations in your code?

Debugging issues related to atomic operations can be challenging due to their thread-safe nature. Techniques for debugging include adding print statements, using specialized tools like Valgrind's Helgrind, and carefully analyzing the behavior of the program under different scenarios.

  1. What are the potential consequences of not using atomic operations when working with shared data in a concurrent program?

Not using atomic operations when working with shared data in a concurrent program can lead to data races, inconsistencies, and other hard-to-debug issues. In extreme cases, these issues can cause the program to crash or behave unpredictably.

  1. What is the role of memory barriers in concurrent programming?

Memory barriers are used to ensure that certain memory accesses happen in a specific order, which can be important for correctness and performance. They help maintain the desired memory ordering between operations and prevent optimizations from reordering memory accesses in ways that could lead to incorrect results or data races.

  1. What is the difference between volatile variables and atomic variables?

Volatile variables are used to indicate that their values may be modified by hardware or other threads, while atomic variables provide thread-safe operations on a single memory location. Volatile variables do not guarantee atomicity, but they can help prevent optimizations that might otherwise introduce race conditions or other issues.

  1. What is the relationship between volatile variables and memory barriers?

Volatile variables can imply the need for memory barriers to ensure that certain memory accesses happen in a specific order. Memory barriers are used to enforce the desired memory ordering between operations, regardless of whether they involve volatile variables or not.