• a generalized lock
• first defined by Dijkstra in late 1960s
  • can behave similarly to mutex lock, but has more sophisticated usage
  • min synchronization primitive used in original UNIX

• originally P() and V() for proberen (test) and verhogen (increment) in Dutch

• idea: serialization

void wait(S) {
  while (S <= 0)
    ; // busy wait
  S--;
}
void signal (S) {
  S++;
}

• can be used: for controlling access to given set of resources
• of finite number of instances
• initialized to: no. of resources available

• can be hav like mutex locks
• 👨‍🏫 but also can be used in different ways

• following code: ensures that $P_1$ process executes $S_1$ before $P_2$ execute $S_2$

P_1: 
  S_1;
  signal(synch);
P_2: 
  wait(synch);
  S_2;

• value (in integer)
• pointer to next record on queue

• block: place process invoking operation to (appropriate) waiting queue
• wakeup: remove one of process in waiting queue
  • place it on ready queue

• w/ classical busy-waiting semaphore: impossible

• magnitude = no. of processes currently waiting on semaphore

typedef struct{
    int value; // if negative: processes being waiting
    struct process *list;
} semaphore;
wait(semaphore *S) {
    S->value--;
    if (S->value < 0) {
        add this process to S->list;
        block();
    }
}
// signal: has chance of changing condition
signal(semaphore *S) {
    S->value++;
    if (S->value <= 0) {
        remove a process P from S->list;
        wakeup(P);
    }
}

• increment & decrement: done before checking semaphore value
• block(): suspends the process & invokes it
• wakeup(P): resumes execution of a suspended process $P$

• forces atomic operation

• for an event: that can be caused oy only one of waiting processes
• e.g. $A,B$: with half-torn treasure map
  • each: request the other part of map
    • without giving up the piece they are holding
    • won't happen!

• $P_0$: waiting for $P_1$ to execute signal(Q)
  • and $P_1$: waiting for $P_1$ to execute signal(S)
  • deadlock!

• process: may never being removed from semaphore queue
  • then: suspended
• e.g. removing process from queue using LIFO
  • w/ certain priorities

• binary

• no. of full slots in buffer

• signal(mutex);
• no. of empty slots in buffer

do {
    // produce item
    wait(empty);
    wait(mutex); // guarantee mutual execution
    // add next produced to buffer
    signal(mutex);
    signal(full); // no. of items in buffer
} while (true);

do {
    // remove item from budder to variable
    wait(full);
    wait(mutex); // guarantee mutual execution
    // consume next item from buffer
    signal(mutex);
    signal(empty);
} while (true);

• readers: only read the data, without performing any updates
• writers: can both read & write

• however, at most one writer can access shared data at a time

• w/ different priorities

• unless: writer as already gained access to shared data
  • shared data update by writers: can be delayed
    • as: people are reading (outdated) version
  • gives: readers priority in accessing shared data

• data set
• semaphore rw_mutex initialized to 1
• semaphore mutex initialized to 1
• semaphore read_count initialized to 0

do {
    wait(rw_mutex);
    // writing
    signal(rw_mutex);
} while (true);

• prevent another writer from reading it!

do {
    wait(mutex); // exclusiveness of following snippet
    read_count++;
    if (read_count == 1)
        wait(rw_mutex);
    signal(mutex);
    // reading performed
    wait(mutex);
    read_count--;
    if (read_count == 0)
        signal(rw_mutex);
    signal(mutex);
} while (true);

• last reader leaving: release the lock (for potential writer)

• first reader gain access to critical section: also waiting on rw_mutex
• all subsequent readers: wait on mutex (held by the first reader)

• simple, yet might result in starvation of writers
  • thus: potential & significant delay of the object's update

• when a writer: waiting for access (either another writer or readers occupying it)
• no new readers: can start reading

• problem: can be solved partially by kernel's reader-writer locks
  • multiple processes: permitted to acquire lock in read mode
  • yet: only one permitted to acquire lock in write mode
• i.e. specifying: the mode of the lock

• when protecting data from short code segments (less than a few hundred instructions)
• starts as: standard semaphore implemented as a spinlock in multiprocessor system
• lock held by a thread running on another CPU: spins to wait for lock
• if held by non-run-state thread: block & sleep waiting
  • for signal of lock being released

• wait until condition satisfies
• uses: readers-writers locks when longer sections of code need access to data
  • used to protect frequently-accessed data
    • used in read-only manner
  • relatively expensive to implement

• for efficiency: threads are never preempted when holding a spinlock

• Windows: provide dispatcher objects
• threads: synchronize according to several different mechanism
  • mutex locks, semaphores, events, timers

prior to kernel 2.6: disables interrupts to implement short critical sections

• 2.6 and later: fully preemptive kernel

provides:

• semaphores
• spinlocks (for multi-processor)
• atomic integer, and math operations involving it
• reader-writer locks

on single CPU: spinlocks replaced by enabling / disabling kernel preemption

atomic variables: like atomic_t

• e.g. variable atomic_t counter; int value;

• mutex locks
• semaphores
• condition variables

#include <pthread.h>

pthread_mutex_t mutex;

/* create and initialize the mutex lock */
pthread_mutex_init(&mutex, NULL);

/* acquire the mutex lock */
pthread_mutex_lock(&mutex);

/* critical section */

/* release the mutex lock */
pthread_mutex_unlock(&mutex);

• associated w/ POSIX mutex lock to provide: mutual exclusion
• 👨‍🏫 must be in combination
• modification of condition variable itself: not guaranteed to be exclusive
  • mutex lock needed

pthread_mutex_t mutex;
pthread_cond_t cond_var;

pthread_mutex_init(&mutex, NULL);
pthread_cond_init(&cond_var, NULL);

• waiting for condition a==b to be true:

  pthread_mutex_lock(&mutex);
  while (a != b)
    pthread_cond_wait(&cond_var, &mutex);
  
  pthread_mutex_unlock(&mutex);
  

  • pthread_cond_wait: in addition to putting the calling thread to sleep
    • release the lock when putting said caller to sleep
    • no other signal: can acquire lock / signal it to wake up
  • it also: release on mutex
    • thus: others can modify the condition..?

  pthread_mutex_lock(&mutex);
  a = b;
  pthread_cond_signal(&cond_var);
  pthread_mutex_unlock(&mutex);
  

  • when signalling: make sure to have the lock held
    • ensures: there is no race condition
  • before returning & being waked up: pthread_cond_wait re-acquires the lock
    • ensures: any time: waiting thread is running "between the lock acquired in the beginning"
    • lock: release at the end

• but there are also situations it can't