Resolving Race Conditions and Critical Sections in C#

Tural Suleymani

2y3.4k19100Article

A race condition in C# occurs when two or more threads access shared data simultaneously, and the outcome of the program depends on the unpredictable timing of these threads. This can lead to inconsistent or incorrect results, making race conditions a critical problem in multi-threaded applications.

In this article, we will learn everything in practice and will try not just to understand but also to resolve the race condition and critical section problems in .NET.

How Race Conditions Occur?

Race conditions typically occur when the following conditions are met.

Shared Resource: Two or more threads are trying to read, write, or modify the same shared resource (e.g., a variable, object, or file).
Concurrent Execution: The threads execute concurrently without proper synchronization mechanisms to control their access to the shared resource.

Race conditions occur when multiple threads concurrently access and modify shared data, leading to unpredictable results.

They arise due to the lack of synchronization, where threads interleave in a way that causes operations to be performed out of the expected order.

A critical section in C# refers to a block of code that must be executed by only one thread at a time to prevent data corruption or inconsistent results due to concurrent access. When multiple threads access shared resources, such as variables or objects, and at least one thread modifies those resources, a critical section ensures that only one thread can execute the code block that accesses the shared resource at a time. This is crucial for maintaining the integrity of the shared data.

Let's directly switch to our example below and explore both worlds.

public class Transaction
{
    public bool IsDone { get; set; }
    public void Transfer(decimal amount)
    {
        if (!IsDone)//critical section
        {
            Console.WriteLine($"Transaction operation started in thread number = {Environment.CurrentManagedThreadId}");
            TransferInternally(amount);
            Console.WriteLine($"Transaction operation ended in thread number = {Environment.CurrentManagedThreadId}");
            IsDone = true;
        }
    }
    private void TransferInternally(decimal amount)
    {
        Console.WriteLine($"TransferInternally in thread...{Environment.CurrentManagedThreadId}, the amount = {amount}");
        Console.WriteLine($"TransferInternally is done in thread...{Environment.CurrentManagedThreadId}, the amount = {amount}");
    }
}

In the provided code, the critical section and the race condition problem relate to how multiple threads might interact with the Transaction class, particularly with the IsDone property and the Transfer method.

Critical Section

A critical section is a part of the code that accesses shared resources (in this case, the IsDone property) and must not be executed by more than one thread at a time. The critical section in your code is.

This block of code is critical because it checks and updates the IsDone property. If multiple threads access this code simultaneously without proper synchronization, it could lead to inconsistent or incorrect behavior.

Race Condition Problem

A race condition occurs when the outcome of a program depends on the timing or sequence of threads executing. In this code, a race condition could happen if multiple threads call the Transfer method at the same time.

Scenario Leading to a Race Condition

Thread 1 checks the IsDone property and finds it to be false.
Thread 1 proceeds with the transaction, outputting the start message and entering the TransferInternally method.
Thread 2 then checks the IsDone property before Thread 1 has finished and still finds it to be false.
Thread 2 also proceeds with the transaction, despite Thread 1 already handling it.

Because both threads find IsDone to be false before either has a chance to set it to true, both threads will execute the transaction, which is not the intended behavior. The property IsDone will only be set to true after both threads have completed their operations, leading to an incorrect situation where the transaction is performed twice.

Here is what Our main method looks like.

static void Main(string[] args)
{
    Transaction2 transaction = new Transaction2();
    for (int i = 0; i < 10; i++)
    {
        Task.Run(() =>
        {
            transaction.Transfer(3000);
        });
    }
    Console.ReadLine();
}

The provided code demonstrates how a race condition problem can occur when multiple threads simultaneously attempt to execute the Transfer method of the Transaction class.

Explanation of the Code

Transaction Instance

Transaction transaction = new Transaction();

Here, a single instance of the Transaction class is created. This instance is shared among all threads that will be created in the subsequent loop.

Creating and Running Tasks

for (int i = 0; i < 10; i++)
{
    Task.Run(() =>
    {
        transaction.Transfer(3000);
    });
}

This loop runs 10 times, and each iteration starts a new task using Task. Run. Each task calls the Transfer method of the transaction object, attempting to transfer the amount of 3000.

Task

Each Task. Run spawns a new thread (or reuses one from the thread pool) to execute the code within the lambda expression. Therefore, up to 10 threads might be running the Transfer method concurrently.

Because there’s no synchronization mechanism like a lock statement, multiple threads could be executing this block simultaneously. This leads to several threads performing the transfer, outputting the start and end messages, and setting IsDone to true.

Race Condition Effect

The race condition occurs because the IsDone check and the subsequent operations are not atomic. This means that even if one thread sets IsDone to true, other threads might have already passed the check and are also executing the transfer, leading to multiple executions of what should be a one-time transaction.

The outcome of the Race Condition

As a result of the race condition, you might see output that indicates the transaction was processed multiple times, even though the logic implies it should only happen once. Each thread will print its messages to the console, showing that multiple threads have entered the critical section and completed the transaction.

The output

To prevent race condition problems and capture the critical section, we will use the lock keyword. Of course, we have multiple ways to avoid these problems but the easiest one is using the lock keyword.

 public class Transaction2
 {
     public bool IsDone { get; set; }
     private static readonly object _object = new object();
     public void Transfer(decimal amount)
     {
         lock(_object)
         {
             if (!IsDone)//should act as a single atomic operation
             {
                 Console.WriteLine($"Transaction operation started in thread number = {Environment.CurrentManagedThreadId}");
                 TransferInternally(amount);
                 Console.WriteLine($"Transaction operation ended in thread number = {Environment.CurrentManagedThreadId}");
                 IsDone = true;
             }

         }
        
     }

     private void TransferInternally(decimal amount)
     {
         Console.WriteLine($"TransferInternally in thread...{Environment.CurrentManagedThreadId}, the amount = {amount}");
         Console.WriteLine($"TransferInternally is done in thread...{Environment.CurrentManagedThreadId}, the amount = {amount}");
     }
 }

Transaction2 result

Transaction

Multithreading Data Integrity ConcurrencyRace ConditionCritical SectionData Corruption

19 Comments

Join the conversation! Your thoughts help the community grow.

Mariusz Postol2y ago
"A critical section in C# refers to a block of code that must be executed by only one thread..." - it is not true - you must consider time. In C# but in Java, Algol, and Fortran it doesn't apply.
- Mariusz Postol2y ago
  "A critical section in C# refers to a block of code that must be executed by only one thread..." - you forgot to add "at any point in time".The critical section is a program pattern that applies to all languages I know.
- Tural Suleymani2y ago
  "A critical section in C# refers to a block of code that must be executed by only one thread..." - it is true and I dont see any time issue in C#
Mariusz Postol2y ago
What is the difference between concurrent and sequential programming? The question refers to compile time, not run time.
- Mariusz Postol2y ago
  "The threads execute concurrently without proper synchronization" and "Concurrent programming at compile time involves writing code that anticipates multiple threads" - You can't explain concurrency using the "thread" term - it is a circular reference - isn't it? What about sequential and concurrent programming compared with parallel programming? My point is that it is exactly in scope and the C# language is not relevant.
- Mariusz Postol2y ago
  Because the "critical section is a pattern aimed at changing concurrent programming to sequential programming thanks to the appropriate synchronization of concurrent activities." it is critical ( in scope) to explain the difference between concurrent and sequential programming.
- Mariusz Postol2y ago
  To learn my point related to sequential programming check out the section:<https://mpostol.gitbook.io/pip/concurrent-programming/concurrentprogramming#sequential-programming> To learn my point related to concurrent programming check out the section: <https://mpostol.gitbook.io/pip/concurrent-programming/concurrentprogramming#sequential-programming> To continue the discussion add comments to a discussion panel on GitHub at <https://github.com/mpostol/TP/discussions>
Mariusz Postol2y ago
"Shared Resource: Two or more threads are trying to read...." - in the case of immutable data it is not true.
- Mariusz Postol2y ago
  Not sure what you mean. I am not saying that the article is wrong, but have doubts related to the selected sentence. My goal is to learn something new but it looks inconsistent. My point is that read operation does not always lead to any problems even in the concurrent environment.
- Tural Suleymani2y ago
  Please read article in carefully. The example is realted to multable data, not immutable
Mariusz Postol2y ago
"This can lead to inconsistent or incorrect results" - do you think that if the result is inconsistent it is correct? What is the difference between inconsistent and incorrect results?
- Mariusz Postol2y ago
  For me, it doesn't address my doubts, but OK; I understand your point.
- Tural Suleymani2y ago
  The terms inconsistent and incorrect results are often used in discussions about concurrency issues like race conditions, but they have different meanings Inconsistent results refer to outcomes that vary between different runs or executions of a program due to non-deterministic behavior, such as race conditions. In other words, the result might change from one execution to another, even if the inputs and operations are the same. Incorrect results are those that do not meet the expected or desired outcome based on the logic of the program. An incorrect result is wrong according to the program's specifications, regardless of how often it occurs.
Mariusz Postol2y ago
You said "A race condition in C# occurs when two or more threads access shared data" - what is the difference between the race condition and the critical section problem? The critical section problem in software engineering arises when multiple concurrent threads access shared resources. My concern is if it is directly coupled with the C# programming language.
- Mariusz Postol2y ago
  "and at least one of them modifies the data. " - it addresses the question related to read operation.
- Mariusz Postol2y ago
  What about a classic definition, the critical section is a programming pattern preventing ..., whereas race condition is a possibility to lead to values inconsistency. Simplifying, critical section is like a restroom - inside must be only one. The race condition is a possibility that the restroom may be used by many. Getting back to IT terminology, the critical section is a pattern aimed at changing concurrent programming to sequential programming thanks to the appropriate synchronization of concurrent activities.
- Tural Suleymani2y ago
  The concepts of race conditions and the critical section problem are closely related, but they are not the same A race condition occurs when the behavior of a software system depends on the relative timing or interleaving of multiple threads or processes. It happens when two or more threads access shared data concurrently, and at least one of them modifies the data. The final outcome of the program may vary depending on the order in which the threads execute, leading to unpredictable and potentially incorrect results. The critical section problem refers to the challenge of ensuring that multiple threads or processes do not simultaneously execute critical sections of code that access shared resources. The goal is to prevent race conditions by ensuring mutual exclusion, meaning only one thread can execute the critical section at a time. The critical section problem is essentially the root cause of race conditions. If the critical section problem is not properly addressed, race conditions are likely to occur.

How Race Conditions Occur?

Race conditions typically occur when the following conditions are met.

Shared Resource: Two or more threads are trying to read, write, or modify the same shared resource (e.g., a variable, object, or file).

Concurrent Execution: The threads execute concurrently without proper synchronization mechanisms to control their access to the shared resource.

Race conditions occur when multiple threads concurrently access and modify shared data, leading to unpredictable results.

They arise due to the lack of synchronization, where threads interleave in a way that causes operations to be performed out of the expected order.

Let's directly switch to our example below and explore both worlds.

public class Transaction { public bool IsDone { get; set; } public void Transfer(decimal amount) { if (!IsDone)//critical section { Console.WriteLine($"Transaction operation started in thread number = {Environment.CurrentManagedThreadId}"); TransferInternally(amount); Console.WriteLine($"Transaction operation ended in thread number = {Environment.CurrentManagedThreadId}"); IsDone = true; } } private void TransferInternally(decimal amount) { Console.WriteLine($"TransferInternally in thread...{Environment.CurrentManagedThreadId}, the amount = {amount}"); Console.WriteLine($"TransferInternally is done in thread...{Environment.CurrentManagedThreadId}, the amount = {amount}"); } }

Critical Section

Race Condition Problem

Scenario Leading to a Race Condition

Thread 1 checks the IsDone property and finds it to be false.

Thread 1 proceeds with the transaction, outputting the start message and entering the TransferInternally method.

Thread 2 then checks the IsDone property before Thread 1 has finished and still finds it to be false.

Thread 2 also proceeds with the transaction, despite Thread 1 already handling it.

static void Main(string[] args) { Transaction2 transaction = new Transaction2(); for (int i = 0; i < 10; i++) { Task.Run(() => { transaction.Transfer(3000); }); } Console.ReadLine(); }

public class Transaction2 { public bool IsDone { get; set; } private static readonly object _object = new object(); public void Transfer(decimal amount) { lock(_object) { if (!IsDone)//should act as a single atomic operation { Console.WriteLine($"Transaction operation started in thread number = {Environment.CurrentManagedThreadId}"); TransferInternally(amount); Console.WriteLine($"Transaction operation ended in thread number = {Environment.CurrentManagedThreadId}"); IsDone = true; } } } private void TransferInternally(decimal amount) { Console.WriteLine($"TransferInternally in thread...{Environment.CurrentManagedThreadId}, the amount = {amount}"); Console.WriteLine($"TransferInternally is done in thread...{Environment.CurrentManagedThreadId}, the amount = {amount}"); } }