Fearless Concurrency

Fearless Concurrency is a core philosophy and feature of the Rust programming language that allows developers to write concurrent code without fear of common concurrency bugs like data races, race conditions, or deadlocks, primarily by leveraging its strict ownership and type system at compile time.

In most other languages, concurrency can be notoriously difficult to get right. Developers often encounter problems like:
* Data Races: When two or more threads access the same memory location concurrently, at least one of them is a write, and there's no synchronization mechanism to order their accesses. This leads to undefined behavior and hard-to-debug issues.
* Race Conditions: When the outcome of a program depends on the relative order or timing of events, such as instructions from different threads.
* Deadlocks: When two or more competing actions are waiting for the other to finish, and thus neither ever does.

Rust's approach to "Fearless Concurrency" primarily tackles data races by guaranteeing their absence at compile time. It achieves this through:

1. Ownership and Borrowing System: Rust's ownership rules ensure that each piece of data has a single owner. When sharing data between threads, Rust's borrow checker prevents simultaneous mutable access. If multiple threads need mutable access to shared data, Rust forces you to use explicit synchronization primitives (like `Mutex`). This fundamentally prevents data races by ensuring that either data is not mutable, or if mutable, only one thread can access it at a time.
2. Type System and Traits (`Send` and `Sync`):
* The `Send` trait indicates that a type can be safely transferred "sent" to another thread. Most primitive types and many standard library types are `Send`. For a type to be `Send`, all its parts must also be `Send`.
* The `Sync` trait indicates that a type can be safely referenced "shared" across multiple threads. If a type `T` is `Sync`, then `&T` (a shared reference to `T`) is `Send`. This means multiple threads can safely hold immutable references to `T` simultaneously. For a type to be `Sync`, all its parts must also be `Sync`.
* These traits are automatically derived for most types that are composed of `Send`/`Sync` types, but they can also be implemented manually (often with `unsafe` code for complex cases, but this is rare in safe Rust).
* Rust's compiler uses these traits to ensure that data is only shared or moved between threads in a way that prevents data races. For example, `std::rc::Rc` (a single-threaded reference counter) is neither `Send` nor `Sync` because sharing it across threads would lead to data races on its internal reference count.

How it works in practice:

* Shared Mutable State: To share mutable data between threads safely, Rust typically requires the use of smart pointers combined with synchronization primitives. The common pattern is `Arc<Mutex<T>>`.
* `Arc<T>` (Atomically Reference Counted) allows multiple ownership of a value on the heap across multiple threads. It's a thread-safe version of `Rc<T>`. When the last `Arc` goes out of scope, the value is dropped.
* `Mutex<T>` (Mutual Exclusion) provides exclusive access to the data it protects. A thread must acquire a lock on the `Mutex` before it can access the data inside. Only one thread can hold the lock at a time, preventing data races.
* Message Passing: Rust also strongly supports message passing concurrency using channels, similar to Go's goroutines and channels. This paradigm encourages sharing memory by communicating, rather than communicating by sharing memory, which can often be simpler and safer for certain concurrency patterns.

By enforcing these rules at compile time, Rust eliminates an entire class of concurrency bugs, allowing developers to write concurrent code with a much higher degree of confidence. If the Rust compiler says your concurrent code compiles, you can be "fearless" that it won't have data races.

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    // Create an Arc<Mutex<i32>> to safely share and mutate an integer across threads.
    // Arc allows multiple threads to own a reference to the same data (reference counting).
    // Mutex ensures that only one thread can access the protected data at a time (mutual exclusion).
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for i in 0..10 {
        // Clone the Arc for each new thread. Each clone increments the reference count.
        // The `move` keyword transfers ownership of `counter_clone` into the new thread's closure.
        let counter_clone = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            println!("Thread {} trying to acquire lock...", i);
            // Acquire a lock on the mutex. This call blocks until the lock is available.
            // `lock().unwrap()` returns a `MutexGuard`, which provides mutable access to the inner data.
            // If any thread holding the lock panics, the mutex becomes "poisoned", and `lock()` will return an `Err`.
            let mut num = counter_clone.lock().unwrap();
            println!("Thread {} acquired lock.", i);

            // Increment the counter. The lock is held during this operation, guaranteeing exclusive access.
            *num += 1;
            println!("Thread {} incremented counter to {}.", i, *num);
            // The `MutexGuard` is automatically dropped here (or at the end of the closure's scope),
            // releasing the lock and allowing other waiting threads to acquire it.
        });
        handles.push(handle);
    }

    // Wait for all threads to complete their execution.
    for handle in handles {
        handle.join().unwrap(); // `join()` blocks the current thread until the target thread finishes.
    }

    // After all threads have finished, acquire the final lock to print the result.
    // This ensures we get the final, consistent value.
    println!("Final counter value: {}", *counter.lock().unwrap());
}