Shared-State Concurrency

Shared-state concurrency is a paradigm in concurrent programming where multiple threads or processes access and modify the same shared memory location or resource. While this approach can be efficient for tasks that require threads to collaborate on common data, it introduces significant challenges related to data consistency and correctness.

The Challenges:

1. Race Conditions: Occur when the correctness of a program depends on the relative timing or interleaving of operations of two or more threads. If multiple threads try to write to the same memory location, or one thread writes while another reads, the final state of the shared data can be unpredictable and incorrect.
2. Deadlocks: A situation where two or more competing actions are each waiting for the other to finish, and thus neither ever finishes. This typically happens when threads acquire multiple locks in different orders.
3. Livelocks: Similar to deadlocks, but threads are not blocked; instead, they continually change their state in response to other threads without making any progress.
4. Starvation: Occurs when a thread is perpetually denied access to a shared resource, even though it becomes available.

Rust's Approach to Shared-State Concurrency:

Rust tackles these challenges with a strong emphasis on safety through its ownership system and powerful type system, which enforce rules at compile time, often preventing many concurrency bugs before runtime.

1. Ownership and Borrowing: Rust's core ownership model ensures that there's always a clear owner for data, and data can be borrowed immutably (multiple readers) or mutably (single writer) at any given time. This eliminates many common data races that arise from aliasing mutable data.

2. `std::sync::Arc` (Atomic Reference Counted): When multiple threads need to *own* a piece of data (i.e., they all need to ensure the data stays alive until they are done with it), `Arc` comes into play. `Arc<T>` is a thread-safe reference-counting pointer. It allows multiple owners of the same data, and the data is only deallocated when the last `Arc` pointing to it is dropped. This facilitates sharing data ownership across thread boundaries. `Arc` itself is thread-safe (incrementing/decrementing the count is atomic), but the data *inside* the `Arc` is not necessarily protected from concurrent modification.

3. `std::sync::Mutex` (Mutual Exclusion): To protect the actual shared data from race conditions (i.e., to ensure only one thread can modify it at a time), Rust provides `Mutex<T>`. A mutex provides mutual exclusion, meaning that only one thread can acquire the lock on the mutex at any given time.
* When a thread wants to access the data protected by a `Mutex`, it must first `lock()` the mutex.
* The `lock()` method returns a `MutexGuard<T>`. This is a smart pointer that dereferences to the inner data `T`.
* Crucially, when the `MutexGuard` goes out of scope (e.g., at the end of a block or function), the mutex is automatically unlocked. This RAII (Resource Acquisition Is Initialization) pattern ensures that locks are always released, even if panics occur, preventing common deadlock scenarios.
* `Mutex` works hand-in-hand with `Arc` when shared data needs both shared ownership and mutual exclusion. You'll often see `Arc<Mutex<T>>`.

4. `std::sync::RwLock` (Read-Write Lock): For scenarios where shared data is read much more often than it's written, `RwLock` can offer better performance than `Mutex`. It allows multiple readers to access the data concurrently, but only one writer can access it exclusively.

By combining `Arc` for shared ownership and `Mutex` (or `RwLock`) for exclusive access to the data, Rust provides a robust and safe way to handle shared-state concurrency, catching many potential bugs at compile time.

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

fn main() {
    // 1. Create a shared counter, protected by a Mutex and shared across threads with Arc.
    // Arc allows multiple threads to 'own' a reference to the same data.
    // Mutex ensures that only one thread can access the counter at a time.
    let counter = Arc::new(Mutex::new(0));

    let mut handles = vec![];
    let num_threads = 10;
    let increments_per_thread = 100_000;

    println!("Starting shared-state concurrency example with {} threads, each incrementing the counter {} times.", num_threads, increments_per_thread);

    for i in 0..num_threads {
        // 2. Clone the Arc for each thread. Each clone is a new owner.
        let counter_clone = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            for _ in 0..increments_per_thread {
                // 3. Acquire the lock on the Mutex.
                // .lock() returns a MutexGuard, which holds the lock.
                // If the lock is already held by another thread, this call blocks until it's available.
                let mut num = counter_clone.lock().unwrap(); // .unwrap() handles potential poisoning

                // 4. MutexGuard allows mutable access to the inner data.
                *num += 1;

                // 5. The lock is automatically released when 'num' (the MutexGuard) goes out of scope
                // at the end of this iteration, due to RAII.
            }
            println!("Thread {} finished.", i);
        });
        handles.push(handle);
    }

    // 6. Wait for all threads to complete.
    for handle in handles {
        handle.join().unwrap();
    }

    // 7. Acquire the lock one last time to read the final value.
    let final_value = *counter.lock().unwrap();
    println!("Final counter value: {}", final_value);

    let expected_value = num_threads * increments_per_thread;
    println!("Expected counter value: {}", expected_value);

    assert_eq!(final_value, expected_value);
    println!("Counter value matches expected value. Shared-state concurrency handled correctly!");
}