Lecture 19

7.1 Race Condition

Occurs when there is missing:

• synchronization
• mutual exclusion

Can be very difficult to locate

How well you can spot a race condition is an index of how good a concurrent programer you are.

---

7.2 No Progress

7.2.1 Live-lock

It is an indefinite postponement of "you go first" on simultaneous arrical of tasks.

Caused by poor scheduling in entry protocol

7.2.2 Starvation

A task does not get executed because it is never on top of the priority list.

Long-term (infinite) starvation is extremely rare.

7.2.3 Deadlock

It is a state where one or mroe processes are waiting for an event that will not occur.

unlike live-lock and starvation, the program does not consume CPU time.

7.2.3.1 Synchronization Deadlock

Failure in cooperation.

int main(){
  uSemaphore s(0);  // start closed
  s.P();            // wait for lock to open
  // but there is no thread that can V on s for the main.
}

7.2.3.2 Mutual Exclusion Deadlock

Failure to acquire a resource protected by mutual exclusion

Also called a "Grid-Lock" in traffic situation.

To prevent the grid-lock, you must not acquire mutual exclusion unless you can fully pass the intersection.

There are 5 conditions for such deadlock to occur

1. A concrete shared-resource requireing mutual exclusion
2. A process holds and wait for another resource
3. Once a process gets access to a resource, the runtime system cannot get it back (no preemption on resource)
4. There exists a circular wait of processes on resources
5. These conditions must occur simultaneously

---

7.3 Deadlock Prevention

7.3.1 Synchronization Prevention

• Eliminate all syncronization from a program
• No communication
• Impossible in most cases

7.3.2 Mutual Exclusion Prevention

1. No Mutual Exclusion
   • Too strong
2. No Hold and Wait
   • you must acquire all the resources at once.
   • this under utilizes the resources
   • you are holding lock longer than you need
   • potential starvation: not all resources may be freed at the same time
3. Allow preemption
   • is dynamic -> is not a static answer
4. No Circular Wait
   • Classic method of preventing deadlock
   • always acquire a lock in the same order
   • called ordered resource policy
   • inefficient: task may hold a lock longer than it may need
5. Prevent simultaneous occurrence

---

7.4 Deadlock Avoidance

Like barging avoidance, this method will allow the deadlock condition to occur.

It allows the program to enter unsafe state but keep it away from deadlock.

Better resourec utilization than deadlock prevention.

7.4.1 Banker's Algorithm

Demonstrate a safe sequence of resource allocations that does not end up in deadlock

Requires a process state its maximum resource needs

steps

1. Have a table of
   • tasks and their maximum possible acquirement of resources
   • tasks and their current acquirement of resources
2. Assume all tasks were to acquire for their maximum resources.
3. With currently available amount of resources, is there a task that can meet their maximum acquirement?
4. If yes, allocate them. Once the task is done, all resources that were allocated to that task will be returned.
5. goto 3 until no task is left
6. if there is a sequence of tasks that exhausts all tasks to be finished, you have a possible way out of deadlock.

upon request for resources, run the above step and see if you have a sequence of tasks. If not, you are in a danger place and should not allow allocation of that resource.

---

7.4.2 Allocation Graphs

have a bipartite graph of tasks and resources

The red line is a request for acquiring a resource.

If there is a cycle in the graph, it may result in deadlock.

If T4 finishes and frees one of R3, T2 gets that R3, so it will not end up deadlock.

To do this, we can either

1. make an isomorphic graph
   which is not easy
   

2. apply banker's algorithm.

   1. If a task is not in await for a resource, assume the task done
   2. Free the resources that the task was holding
   3. see if any of free resources can be allocated to tasks that is in await
   4. repeat
   5. if we can remove all arrows and tasks from the graph, the system is not in deadlock

   This can be expensive to apply for all resource allocation within the system

---

7.5 Detection and Recovery

Let the deadlock happen and recover it later.

To do this, we need a way to:

1. detect a deadlock
2. preempt resources

This can much cheaper than avoiding deadlock.

There is uC++ debugging macros to locate deadlock.

• Use GDB macro for this

The question is "what do you do with preempted task"

There is no easy option :/

The task that has been preempted may have been holding the resources because it was modifying it.