In this POC (Proof of Concept), we will explore how the Rust language treats race conditions, comparing it with C , a widely used language, but with fewer security guarantees for competition.

Rust Threads safety: A Comparison with C

Threads Safety: Data Races from C to Rust

Index

• 1. Introduction
• 2. Threads
• 3. Implementation in C
  • 3.1. Code without Protection Against Race Conditions
  • 3.2. Fixing with Mutex
• 4. Implementation in Rust
  • 4.1. Problem with Race Conditions
  • 4.2. Resolution with Mutex and Arc
  • 4.3. Mutex vs. RwLock
• 5. Conclusion
• 6. References

1. Introduction

In computing, threads are used to divide software tasks into subtasks that can be executed concurrently. By using threads, we gain processing time and make better use of the machine's resources, but this competition brings challenges, such as race conditions, which can generate serious inconsistencies in the data.

2. Threads

Threads are execution units that allow you to process tasks simultaneously. We can think of threads as independent flows of execution within a program, illustrated in the image below:

While threads bring performance advantages, they introduce risks, especially when accessing shared resources.

In addition, threads can be used to implement parallelism, where multiple tasks are executed simultaneously on different CPU cores. This allows the program to make better use of the available hardware, speeding up the execution of independent tasks.

3. Implementation in C

Let's create a simple system in C:

1. An initial balance of 1000.
2. A set of transactions that can be credits or debits.
3. Parallel processing of these transactions using threads.

3.1. Code without Protection Against Race Conditions

When we opt for an environment with multithreading processing what we call race conditions can happen, when 2 threads access and modify the same value we have a race condition. This problem occurs because synchronization of the value accessed in each thread is not guaranteed due to competition between calls.

When executing this code several times, the final balance varies, as threads access and change balance simultaneously.

3.2. Fixing with Mutex

Mutex is a synchronization primitive that ensures that only one thread has access to a shared resource at a time. The acronym mutex comes from the English term mutual exclusion, which means "mutual exclusion".

When a thread acquires a mutex, any other thread attempting to acquire the same mutex is suspended until the first thread releases the mutex. This prevents two or more processes (threads) from having simultaneous access to the shared resource.

4. Implementation in Rust

Thinking of Rust as a language absent from data race is not productive, but we can understand how structs and its compiler contribute by bringing great features for memory and thread safety.

Rust treats race conditions with compile-time guarantees, using features such as ownership, borrowing and concurrency-safe structures:

• Arc: Secure sharing of immutable data.
• Mutex and RwLock: Access control for mutable data.

4.1. Problem with Race Conditions

Without the use of Arc and Mutex structs

Rust does not allow direct access to mutable data (balance) from multiple threads without protection.
The compiler will generate an error because balance is being moved to multiple threads (handle1 and handle2) without a safe mechanism.
Error message that will be displayed is:

4.2. Resolution with Mutex and Arc

Using Mutex and Arc we were able to compile and execute our code, with the race condition issues addressed.

4.3. Mutex vs. RwLock

Mutex and RwLock are used to handle race conditions, each with specific advantages:

Mutex: Guarantees exclusive access to a resource for one thread, blocking access to others until it is released. It's simple and effective, but even reads block the resource, making it less efficient in read-heavy scenarios.

RwLock: Allows multiple simultaneous reads with .read() and restricts exclusive writing with .write(). It is Ideal for scenarios with a predominance of reads, as it improves performance by allowing parallelism in read operations.

5. Conclusion

The comparison between C and Rust highlights different approaches to solving race conditions. While C requires attention to avoid race condition errors, Rust reduces these risks at compile time, through tools such as Mutex, RwLock and Arc in addition to the ownership model. This not only makes the code more secure, but also reduces the programmer's mental load by avoiding silent bugs.

In summary, Rust positions itself as an excellent choice for developing competing systems, offering security and reliability.

6. References

• Repo with codes: https://github.com/z4nder/rust-data-races
• https://en.wikipedia.org/wiki/Race_condition
• https://blog.bughunt.com.br/o-que-sao-vulnerabilidades-race-condition/
• https://medium.com/cwi-software/spring-boot-race-condition-e-ambiente-multi-thread-263b21e0042e
• https://learn.microsoft.com/en-us/troubleshoot/developer/visualstudio/visual-basic/language-compilers/race-conditions-deadlocks
• https://www.reddit.com/r/rust/comments/18faxjg/understanding_threadsafety_vs_race_conditions/?rdt=52263
• https://doc.rust-lang.org/nomicon/races.html
• https://news.ycombinator.com/item?id=23599598

The above is the detailed content of Rust Threads safety: A comparison with C.. For more information, please follow other related articles on the PHP Chinese website!