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.
Threads Safety: Data Races from C to Rust
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.
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.
Let's create a simple system in C:
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.
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.
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:
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:
Using Mutex and Arc we were able to compile and execute our code, with the race condition issues addressed.
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.
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.
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!