• 👨‍🏫 yes, given particular RAG: we can identify the deadlock
• then, is it possible to check all possible states of a program
  • 👨‍🏫 theoretically, yet not feasible

• e.g. smart contracts also apply similar idea (e.g. mutex) to prevent reentrancy
• how can we coordinate it across multiple computers? Do we consider each computer as a core?
  • 👨‍🏫 we still consider each computer core as individual cores
• 👨‍🏫 we can't even work it out for a single computer, how can we do so for entire network?
  • overhead will be too much: 10 ~ 20 times slower
  • we usually do something similar to deadlock detection

• can we do similar to programs, so that there won't be issues?
• 👨‍🏫 too complex, it won't be feasible
• 👨‍🎓 it would be to compress all as a docker-like gigantic and atomic multi-core process
  • can we really call that as a single process at this point?

• in that they check problem regularly
• 👨‍🏫 yes

Deadlock in multi-threaded application

• order of threads running: depending on CPU scheduler
  • identifying testing deadlocks: hard
  • as they may occur only under certain scheduling circumstances
• example code

  code
  

• deadlock with lock ordering

  void transaction(Account from, Account to, double amount) {
      mutex lock1, lock2;
      lock1 = get_lock(from);
      lock2 = get_lock(to);
      acquire(lock1);
          acquire(lock2);
              withdraw(from, amount);
              deposit(to, amount);
          release(lock2);
      release(lock1);
  }
  

  • transactions: execute concurrently
  • 1 transferring 25 from A to B, 2 transferring 50 from B to A
  • 👨‍🏫 we can have deadlock among any no. of processes (not just 2)

System model

• system:consist of resources
• resource types: $R_1,R_2,\dots ,R_m$
  • $n$: no. of types of resources
    • not no. of resources
  • e.g. CPU cycles, memory spaces, files, IO devices, semaphores...
• each resource type $R_i$: w/ $W_i$ instances
• each process $P_i$: utilizes a resource as follows
  • request
  • use
  • release

Deadlock characterization

• deadlock involving multiple processes: arise if following 4 conditions hold simultaneously
  • necessary to not sufficient conditions
  • 👨‍🏫 sufficient condition not known
• mutual exclusion: only ne process at a time: can use a resource
• hold and wait: a process holding a resource, waiting to acquire additional resource (held by anther)
• no preemption: resource: can be released only voluntarily by process holding it
• circular wait: set of $n$ waiting process s.t.
  • $P_i$ waiting for resource held by $P_{i+1}$
  • and $P_n$ for $P_1$
• if there is dead lock -> conditions hold
  • is any of the condition doesn't hold -> no dead lock

Resource-allocation graph

• let graph $G=(V,E)$
• $V$: partitioned into two types
  • bipartite!
  • $P=\{P_1,P_2,\dots ,P_n\}$: set of all processes in system
  • $R=\{R_1,R_2,\dots ,R_n\}$: set of all resource types in system
• request edge: directed edge $P_i\to R_j$
  • 👨‍🎓 please give me this resource!
• assignment edge: directed edge $R_j\to P_i$
  • 👨‍🎓 this resource belong to xxx!
• example
  • 
  • 1 instance of $R_1$
  • 2 instances of $R_2$
  • 1 instance of $R_3$
  • 3 instance of $R_4$
  • $T_1$: holds one $R_2$ and waiting for $R_1$
  • $T_2$: holds one $R_1$, one $R_2$, waiting for $R_3$
  • $T_3$: holding one $R_3$
  • 👨‍🏫 no circular wait: no deadlock (for this instance / snapshot)
• example, with deadlock
  • 
  • cycles exist:
    • $P_1\to R_1\to P_2\to R_3\to P_3\to R_2\to P_1$
    • $P_2\to R_3\to P_3\to R_2\to P_2$
  • processes $P_1,P_2,P_3$: deadlocked
• graph with a cycle, yet no deadlock
  • 
  • cycles exist, yet no deadlock
• basic facts
  • if a graph has no cycle: no deadlock
  • if a graph contains a cycle: system may / may not be in a deadlocked state
    • if only one instance per resource type: then deadlock
    • if several instances per resource type: possibility of deadlock

Methods for handling deadlocks

• ensure that: system will never enter a deadlock state
  • deadlock prevention: ensure at least one of the necessary conditions cannot hold
  • deadlock avoidance: requires additional information
    • given in advance, concerning
• deadlock detection: allow system to enter a deadlock state
  • periodically detect: if there is a deadlock & recover from it
  • 👨‍🎓 ~= garbage collector?

Deadlock prevention

• mutual exclusive: unavoidable
  • some resources: cannot be shared!
• hold & wait: must guarantee: whenever a process request a resource, it doesn't hold any other resources
  • require: each process to request and allocated all its resources before execution
    • request resources only when process: has none
  • disadvantages: low resource utilization, possible starvation
• no preemption:
  • preempt resource occupied by another resource
    • preempted resource: added to waiting resource
  • process: will be restarted only if all its old resources are regained
  • only for resources w/ state being easily saved & restored
    • e.g. registers, memory space, and DB transactions
    • cannot be generally applied ro resource (e.g. locks, semaphore)
• circular wait: impose total ordering of all resource types
  • require: each process requests resources in an increasing order of enumeration
    • thus: must request $R_j$ before $R_i$ if $j>i$
  • can be proved by contradiction
    • let: set of processes involved in circular wait: $p=<P_0,P_1,\dots ,P_n>$
    • $P_i$: awaiting for $R_i$, held by process $P_{i+1}$
    • $P_n$: waiting for $R_n$ held by $P_0$
    • implies: $R_0<R_1<R_2\cdots <R_n<R_0$
    • $R_0<R_0$: impossible
      • thus, there can be no circular wait
  • 👨‍🏫 same problem as hold & wait: very slow
    • problem: request resource much earlier than needed / expected

Circular wait example

• invalidating circular wait condition: most common
  • assign each resource (i.e. mutex locks): unique number
  • resources: must be acquired in order
• code

  first_mutex = 1
  second_mutex = 5
  

Deadlock avoidance

• requires: system w/ additional a priori information available
  • e.g. w/ knowledge of complete sqe. of request and release for each process
    • system: can decide for each request whether process should wait to avoid a possible future deadlock
  • simples & most useful model:
    • requiring each process declaration on max no. of resources of each type
    • that it might need (worst case)
  • deadlock avoidance algorithm: dynamically examining resource-allocation state
  • de ensure: circular-wait condition can never exist
• resource allocation state: defined by
  1. available resources
  2. allocated resources
  3. max demand of processes

⭐⭐ Safe state

• when a process: request an available resource
  • system: must decide whether allocation will leave system in safe state
• system: in safe state if there exists a safe sequence $<P_1,P_2,\dots ,P_n>$ consisting all processes in systems
  • s.t. for each $P_i$, resource $P_i$ can still request:
    • can be satisfied by currently available resources + resources held by all $P_j$ for $j<i$
      • i.e. can be freed by execution of $P_i$
      • 👨‍🏫 $P_i$: not waiting for anybody
  • 👨‍🏫 procedure: find $P_1$ s.t. it can be executed w/o any need for waiting
• i.e. if $P_i$: resource needs not immediately available:
  • $P_i$: can wait until all $P_j$ have finished
  • when $P_j$ finished: $P_i$ obtain needed resources, execute, return allocated resources & terminate
  • when $P_i$ terminates, $P_{i+1}$: obtain needed resources, and so on
• if no such seq. exist: system state is unsafe
  • 👨‍🏫 not saying that there must be a deadlock
  • i.e. no immediate solution found!
• ⭐ basic facts
  • if system is in safe state: no deadlocks
  • if a system is in unsafe state: possibility of deadlock
  • 

Avoidance algorithms

• single instance of a resource type
  • use resource allocation graph
• multiple instances of a resource type
  • use Banker's algorithm

Resource-allocation graph scheme

• simply check: whether there exists a cycle
  • 👨‍🏫 if so: deadlock!

Banker's algorithm

• multiple instances
• each process: must declare priori maximum usage
  • if resulting state is unsafe: don't allocate resource!
• when process requests a resource: wait
• check if: allocation result in a safe state / not
• when process
• similar to banking loan system

Data structure for Banker's algorithm

• $n$: no. of processes, $m$: no. of resources types
• available: vector of length $m$
  • if available[j] = k, then $k$ instances of type $R_j$ available
• max: $n\times m$ matrix
  • if Max[i,j] = k, then $P_i$ may request at most $k$ instances of $R_j$
• allocation: $n\times m$ matrix
  • if Allocation[i,j] = k, $P_i$ currently allocated $k$ instance of $R_j$
• need: $n\times m$ matrix
  • if Need[i,j] = k, then $P_i$ may need $k$ more instances of $R_j$ tom complete tasks
  • ⭐⭐ Need[i,j] = Max[i, k] - Allocation[i, j]
  • maximum s.t. process can request additionally
    • ensure: the accumulated request doesn't exceed maximum
      • i.e. check validity / legitimacy
• 👨‍🏫 above properties: defines snapshot

Safety algorithm

• input: state

1. let work & finish: vectors of length $m,n$
   • initialize:
     • Work = Available
     • Finish[i] = false for i ∈ [0, n-1]
2. find $i$ s.t. both
   • Finish[i] = false
   • Need_i ≤ Work
3. Work = Work + Allocation_i
   • Finish[i] = true
   • go to step 2
4. if Finish[i] == true for all $i$: system is in a safe state
   • otherwise, unsafe

Resource-request algorithm for process $P_i$

• input: request
• request: request vector for process $P_i$