Lecture #6

Administrivia

• lab 2 revised

  • minor changes

• pthreads: detached vs. joinable threads

• shorter recap (by popular demand)

• mmap

Our Story So Far (Abbreviated)

• interprocess communication

  • pipes (regular or named)
  • Poxix vs. SysV IPC
  • SysV IPC
    • message queues
    • semaphores
    • shared memory
      • special handling of memory map in kernel process control block

• low-level interfaces: void pointer (typeless) & size

  • most-general interface given that compiled code (i.e. libraries) does not have type info
  • cast pointer to type in client code
  • use sizeof operator to get size (#bytes) of object

• message passing is safer (easier to reason about, hence less error-prone) than shared memory

• networking: preferred IPC mechanism because you can put processes on different machines (or not)

  • unless you need faster performance on single machine

• threads vs. processes

  • threads
    • single process running single program
    • multiple concurrent paths of execution
    • shared resources (memory, file descriptors, etc.)
    • separate call stacks
    • wild pointers can clobber other threads
      • difficult to debug
    • advantages: lighter weight, faster context switching

• thread implementation

  • 1:1 (kernel support)
  • many:1 (library support) -- green threads
  • many:many (multiplex) -- Erlang, Go

• distributed convex hull: more logically implemented using threads

  • except for pedagogical value

• Posix Threads:

  • pass in pointer to function that takes void pointer & returns void pointer
  • pass in void pointer argument
  • use casting in client code
  • join terminating threads to get return value

More About Pointers

• types: compile-time concept

  • machine code deasl with bytes, words, addresses
  • higher-level languages include type info in rutime
    • e.g Java reflection

• C was designed as a high-level assembler

  • considered low-level by modern standards
  • allows precise contol of memory

• struct: lay out in memory may include padding

  • C++ class is struct with optional hidden pointer field

Observations:

struct S1 {
    char c1;
    char c2;
    int i;
};

struct S2 {
    char c1;
    int i;
    char c2;
};

Note:

• sizeof(S1) == 8 but sizeof(S2) == 12

• array: `a[i] == (&(a[0]) + i * sizeof(a))

  • array is pointer: a == &(a[0])
  • pointer arithmetic:
    • p + i is same as (char *) p + i * sizof(*p)
    • a[i] == *(a + i) == *(i + a) = i[a]
      • counterintuitive, but legal C code

• casting: lets programmer assert (to compiler) that block of memory corresponds to a type

• void *: untyped address

  • can't do arithmetic because we don't know the size
  • traditionally (pre-ANSI), used char * for this purpose
    • arithmetic and pointer arithmetic same for char * because byte is smallest addressable unit of memory (sizeof(char) == 1)

• pointer to function: use address of function entry point

  • cannot do pointer arithmetic on function pointer
  • not meaningful to dereference function pointer but we can call a function through a pointer
  • uses:
    • parameterizing behavior
    • abstracting out decisions
  • e.g. sorting arguments: pointer, size of element, number of elements, how to compare
    • comparison function (min, max, sort): given pointers to two elements, return <0, =0, >0 for less-than, equal, greater-than
  • e.g. dynamic dispatch
    • struct Animal{void (*speak)();};
    • dog.speak() --> woof
    • cat.speak() --> meow
    • C++ compiler does this for you automagically (virtual functions)

Critical Section

• critical section: region of code which only one process at a time may execute

  • i.e. concurrent execution would be problematic

• may be a performance bottleneck

• requirements:

  1. mutal exclusion
     • i.e. only one process at a time may proceed
  2. progress
     • when the critical section is open, the system must decide among waiting processes
     • i.e. something must be allowed to execute
  3. bounded waiting
     • a process cannot wait indefinitely (starvation)

Synchronization

• race condition
  • two threads need to update some data structure
  • update is not atomic
  • back luck (worst-case) timing: updates overlap

canonical example:

// process/thread 1:
current_balance = account.get_balance()
new_balance = current_balance + paycheck
account.update(new_balance)

// process/thread 2:
current_balance = account.get_balance()
new_balance = current_balance - withdrawl
account.update(new_balance)

• sequential execution ok: either transaction may come first

• concurent execution: problematic

  • i.e one transaction can "disappear"

TODO: diagram

Synchronization techiques

• mutex (mutual exclusion)
• semaphore
  • common interview question: what's the difference between a mutex and a semaphore
• condition variable
  • used with mutex
  • mutex + condition variable ≈ semaphore
• monitor

Software Solution: Decker's Algorithm

• Decker's algorithm

  • solution for 2 threads only
  • will not work on modern hardware (caching)
  • interesting:
    • historical value
    • intrinsically beautiful

• naive approaches fail:

  • declare "I'm using": race condition
  • yield by turns ("your turn"): deadlock

• reasoning about concurrent processes is hard

• solution: combine both approaches

TODO: diagram & pseudocode

```

```

Hardware Support

• atomic operations

  • test-and-set
  • swap

• e.g.: test & set

  • 1: has lock
  • 0: lock is free
  • test & set to 1 to acquire lock
    • if value was already 1, somone else already has the lock and you left the value unchanged

Semaphore vs. Mutex

• for most practical purposes, a mutex is a binary semaphore

  • subtle semantic difference
    • mutex is tied to process/thread (ownership)
      • may allow recursive locks
      • may protect against priority inversion
      • may be automatically released if process dies
    • (binary) semaphore is tied to resource (signaling)
      • process requesting resource waits until resource is available

• for full capability of semaphore, need to combine mutex (exclusive access) with condition variable (signaling)

• example: protecting a dictionary vs process that requires exclusive access to ditionary

  • difference is subtle
    • usually only important to purists and pedants

Semaphores

• Dijkstra (Dutch Computer Scientist, you may have heard of him) ~1962/63

• OS-level service: "convenient" interface

  • avoid busy waiting (spin locks)

• Semaphore S

  • initial value
  • 2 operations: P(), V()

• P(): Proben

  • aka wait() or down()
  • decrements counter, waits if counter == 0

• V(): Verhogen

  • aka signal() or up()
  • increments counter
  • if counter was 0, wakes up one waiting process (if there is one)

• mutex: more-or-less binary semaphore

  • but purist will cringe when you say that
  • google it: understand it, impress your intervieweres
  • semantic difference: ownership
    • mutex protects the code block
    • semaphore is for signaling (protects the resource)
  • informal terminology: mutex aka lock

Pthread Mutex

#include <pthread.h>

int pthread_mutex_init(
    pthread_mutex_t *mutex,
    const pthread_mutex_attr_t *attr
);
// if attr is NULL, use default values

pthread_mutex_lock(pthread_mutex_t *mutex);

pthread_mutex_unlock(pthread_mutex_t *mutex);

• polling: pthread_mutex_trylock

Condition Variables

example: producer-consumer pair: producer and consumer must have exclusive access (mutual exclusion) to buffer, but consumer must also wait until the buffer is not empty to proceed

polling:

while !done
   get mutex
   if condition
      process()
      done = true
   release mutex

• mutex guarantees exclusive access, but polling for condition is expensive

• pthread condition variable is used to tell process to wake up and check to see if condition holds (e.g. is buffer non-empty)

  • terminology alert: condition variable is not the underlying condition; condition variable is used to signal
    • e.g. underlying condition is desired buffer state

condition varible:

while !done
   get mutex lock
   while !condition
      wait on condition variable
   if condition
      process()
      done = true
   release lock

• operations for condition variable:
  • wait
  • signal
    • semaphore may also use signal
    • system: signal(2)
  • broadcast
    • thundering herd problem

Pthread Condition Variables

int pthread_cond_init(
    pthread_cond_t *cond,
    const phtread_condattr_t *attr  // NULL for default settings
)

int pthread_cond_signal(pthread_cond_t *cond);

int pthread_cond_wait(
    pthread_cond_t *cond,
    pthread_mutex_t *mutex
);

• wait with timeout: pthread_cond_timedwait

  • always use a timeout when writing systems

• all waiters must use same mutex

  • only call pthread_cond_wait when holding the mutex
    • mutex is released during wait, reacquired before returning from wait

• possible to have spurious returns from pthread_cond_wait()

  • code must check underlying condition before proceeding
    • do not rely on condition variable (return from wait)
  • must use loop to check until condition holds (safe to do so because you hold the mutex)

Semaphores (Again)

• non-binary semaphores may be implemented using
  • mutex (mutual exclusion)
  • condition variable (signaling)
  • counter

Monitors

• language-level implementation, e.g protected { // code }

• only one thread at a time may enter protected (monitor) block

  • unless thread is waiting on a condition (variable) inside the monitor
  • when condition is true and thread regains exclusive access, thread may continue

• Java: synchronized blocks

can implement monitor in C++ using RAII (Resource Allocation Is Initiation):

{
  // unprotected code
  {
    // more unprotected code (optional)
    Monitor m();  // constructor acquires lock
    // protected code
    m.wait_for(signal_var)  // optional
    // more protected code
   }  // destructor releases lock, called automagically on object m when leaving scope
   // even more unprotected code
}