Mutex / Mutual Exclusion / Locking mechanism / Block / Sleep

if 1 thread is in CS other cannot enter, Return value: None, Parameters: None

Mutex internal implementation

A mutex is shared state + rules for deciding which thread may enter a critical section.
mutex's state is stored in ordinary memory owned by the program (often in the mutex object). other cores.
Once thread asks for mutex, kernel checks that value and puts the calling thread on a wait queue and schedules it out. Checking the value as part of waiting prevents a wake-up from being lost if the mutex was unlocked just before the thread went to sleep.
In short, the CPU performs the fast atomic lock operation, while the kernel is typically involved only when a thread must sleep or be woken. library.

Problems with Mutex

Problem Description
Priority Inversion Lower priority process is executing in Critical section, suddenly High-Priority process is scheduled, lower-priority process is preempted & thrown out of CS & higher priority process excecutes in CS. Also if Higher priority thread/process is Busy Waiting then lower priority process will never get CPU(ie never scheduled).
Can PI happen on user-level threads? No, there is no preemption in user level threads.
Easy Deadlock if order of mutex locking/unlocking is not correct, that can led to easy dead-lock situation. See Dead-lock example.
Thread holding mutex paniced if thread-1 which holding the lock panics, whole process would panic.
Mutex and data are seperate Entities Thread-1,2 are accessing data using mutex, But thread-3 changed the data without mutex, this should not Happen.
Solutions:
1. Making mutex and data as single entity as done in Rust
2. All times keeping in mind that data should not handled outside mutex guards

#include <iostream>
#include <thread
#include <mutex>

std::mutex m;
int a = 1;
void test(int tid) {
    m.lock();
    a++;
    std::cout << "Thread-" << tid << ", a=" << a << "\n";
    m.unlock();
}
int main() {
    std::thread t1(test,1);
    a += 10;                                //But Thread-3=Main changed data without mutex.
    std::thread t2(test,2);                 //Thread-1,2 will access data using mutex.
    t1.join();
    t2.join();
    return 0;
}
$ ./a.out
Thread-1: 5
Thread-2: Random value

Creating Mutex

C++11 POSIX Rust 

int var = 0;
mutex m;
void fun(int tid) {
    m.lock();
    cout << "tid: " << tid << ", var: " <<  var++ << "\n";
    m.unlock();
}
int main() {
    int a = 1;
    int num_of_thrs = 5;
    thread t[num_of_thrs];
    for (auto i = 0; i < num_of_thrs; i++)
    {
        t[i] = thread(fun, i);
    }

    for (auto i = 0; i < num_of_thrs; i++)
        t[i].join();
    return 0;
}
/*
Without mutex:  //2 threads enter function at same time
tid: 1, var: 0
tid: 3, var: 1
tid: 4, var: 2
tid: tid: 2, var: 3
0, var: 4

With mutex:
tid: 0, var: 0
tid: 3, var: 1
tid: 4, var: 2
tid: 1, var: 3
tid: 2, var: 4
*/
          
       
#include <pthread.h>
#include <stdio.h>

int counter;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

void *fun() {
    //Thread-2 sleeps until Thread-1 unlocks the mutex
    pthread_mutex_lock(&lock);
    printf("Inside CS\n");
    pthread_mutex_unlock(&lock);
}

int main(){
    pthread_t tid1,tid2;  //Defined as int
    pthread_create(&tid1,NULL,&fun,NULL);
    pthread_create(&tid2,NULL,&fun,NULL);

    pthread_join(tid1, NULL);
    pthread_join(tid2, NULL);
}
 In Rust, data and mutex are not seperate. ie data can be accessed inside mutex only.
This solves the problem which we is present in CPP
use std::sync::Mutex;
fn main() {
    // Create mutex and associate a i32 data with it(whose initial value=5).
    let mtx = Mutex::new(5);
    {
        //After acquiring lock, data inside mutex can be changed
        let mut n = mtx.lock().unwrap();     
        *n = 6;
    }
    {
        // Print after acquiring the lock
        let n = mtx.lock().unwrap();
        println!("{}", n);
    }    
}

Wrappers around mutex

lock_guard, unique_lock

These are classes which owns mutex and provide RAII

lock_guard (smaller=faster) unique_lock (heavy wrt lock_guard)
What We donot need to unlock this mutex,
When lock_guard object goes out of scope, mutex is automatically unlocked 		Feature rich version of lock_guard
Features Not copy construtible. Move Assignable.
Because operator = is deleted. 		Move Assignable(yes), copy construtible(no)
Properties
1. Lock/unlock again after 1st lock.
2. Can be moved to other object
3. deferred locking: Acquire the mutex but donot lock immediately
4. time-constrained attempts at locking: try_lock_for(), try_lock_until()
5. recursive locking
Code 
int var = 0;
mutex m;

void fun(int tid) {
  // unlike mutex, lg.unlock() is not needed
  lock_guard <mutex> lg(m);
  cout << "tid: " << tid << ", var: " <<  var++ << "\n";
}
 Immediate lock
mutex m;
void fun(int tid) {
    unique_lock <mutex> ul(m);
    // Do some work here
    ul.unlock();    // unlock early
    // Do other work without the lock
    ul.lock();      // lock again
}


unique_lock <defer_lock>
- Donot lock immediately. Most of deadlock problem occur because of immediate mutex locking.
- defer_lock delays locking on mutex for some time. defer_lock example(Deadlock)
std::mutex mtx;
void task() {
    // Construct unique_lock, donot lock mutex immediately
    unique_lock <mutex> lock(mtx, defer_lock);

    // Do some work while the mutex is NOT locked...

    // Now, manually lock the mutex when you actually need it
    lock.lock();
    // Critical section
} // The destructor of 'lock' will automatically unlock mtx when it goes out of scope

int main() {
    thread t(task);
    t.join();
    return 0;
}

1 Writer, Multiple Readers

#include <shared_mutex>
std::shared_mutex mtx;

// For read-only operations (e.g., getCurrentCount)
shared_lock <std::shared_mutex> rlock(mtx); // multiple readers allowed

// For write operations (e.g., allowRequest when it modifies state)
unique_lock <shared_mutex> wlock(mtx); // single writer