1. Synchronization

2. Concurrency

3. Shared Address Space
Threads in the same process share memory address space.
The OS can preempt the currently running thread at ANY time.
What does this mean when updating shared memory?

4. Question
What do we think the result of this program will be.

5. Question
Why do we get that result? More importantly why is the result non- deterministic?

6. Critical Sections
Critical Section: An area of code that accesses shared memory from concurrent programming (threads or processes).
Race Condition: When the output of a program is dependent upon the order in which its concurrent constituents are run (results in incorrect behavior).
Race conditions might be 1 in 10,000 and are notoriously hard to debug and solve.

7. Mutual Exclusion
Mutual Exclusion: Only one thread can enter a critical section at the same time.
Solution must be free of deadlocks.
Deadlock occurs when two or more processes/threads are waiting on each other in such a way that they will never wake up.

8. Four Conditions for Mutual Exclusion
No two processes are simultaneously in the corresponding critical section
No assumptions are made about speeds or numbers of CPUs available.
No process running outside of a critical section may block another process that wants to enter a corresponding critical section (or is in the critical section).
No process must wait forever to enter its critical section.

9. Attempted Solutions: Interrupts
Solution #1: Turn off Interrupts (happens in HW) before you enter critical section, turn-on interrupts afterwards.
Interrupts are what allows the CPU to run something other than its current path of execution (current thread).
By disabling interrupts the code will be atomic. An atomic section of code (or code run atomically) will run without interruption.
What about long critical sections? What happens if the program halts in critical section? Or if divide-by-zero? Or is malicious?

10. Attempted Solution: SW Flag
Have a shared flag that is set to ‘0’ when the critical section is empty and ‘1’ when it is occupied.

11. Question
Where can we insert an interrupt to cause incorrect execution?

12. Flag Problem
A multi-perspective episodic approach, Jae C. Oh

13. Test-and-set
An atomic operation (supported in instruction set and HW).
Writes a ’1’ into a memory value and returns the previous value.
Used with busy-waiting.
Modern Operating Systems, 3rd ed., Andrew Tanenbuam 

14. Question
Problems with Busy Waiting?

15. Semaphores

16. Busy waiting issues Inefficient CPU usage. Priority inversion issues
Better Idea: Instead of busy waiting for the critical section to become available, block the requesting process.

17. Semaphore

18. Semaphore Implementation

19. Interrupts? Didn’t we say disabling interrupts were dangerous?
Yes we did
Class Semaphore exists only in the kernel.
System call needed to invoke functions.
Critically important disabling/enabling interrupts are handled correctly.
Luckily this is done by OS designer, not application developer!
Other implementations using test-and-set.

20. Semaphore Usage
A multi-perspective episodic approach, Jae C. Oh

21. Mutex: Binary Semaphore
A Mutex is a Semaphore with a single count.
Mutex is best for critical sections.

22. Implementation of mutex_lock and mutex_unlock
Mutexes in assembly
Implementation of mutex_lock and mutex_unlock

23. Question
Why Counting Semaphore?

24. Monitors

25. Problems with Semaphores
Semaphores and monitors can be prone to errors.
Acquire & release must be put in the correct location other wise program can seize up.
Very hard to debug if only triggered via a race condition.

26. Monitors
Monitors are a higher-level construct (i.e. part of a programming language).
Only 1 thread allowed in a monitor procedure at a time (imagine the methods are wrapped by mutex.p() and mutex.v()).
Condition variable: A queue of threads waiting for some condition to become true. 0 or more can be associated with a monitor.

27. Condition Variables
Within a monitor, calling wait on a conditional variable will cause the current thread to sleep on the condition variable. The thread releases the lock.
When another thread calls signal on the conditional variable, one of the blocked threads is allowed to progress.
The thread calling signal, must own the monitor lock.
Broadcast will unblock all of the blocked threads.
Signal has no effect if no threads are blocked (i.e. no count variable associated with condition variables).

28. Producer Consumer with Monitors
Modern Operating Systems, 3rd ed., Andrew Tanenbuam 

29. Java Monitors Java supports monitors via synchronized keywords.
Synchronized methods within a class can only be accessed by one thread per instance of the class (not across all instances of the class).
Synchronized statements, allow arbitrary sections of code to be synchronized on any Java Object.
Java Object class supports wait and notify (also notifyall).

30. Classical Semaphore Problems

31. Producer And Consumers
Two types of workers: producer, consumer.
Producer generates data and writes it to a queue. If the queue is full producer sleeps.
Consumer, consumes data from the queue and sleeps if the queue is empty.
Fixed length queue.

32. Classical Semaphore Problems

33. Producer And Consumers
Two types of workers: producer, consumer.
Producer generates data and writes it to a queue. If the queue is full producer sleeps.
Consumer, consumes data from the queue and sleeps if the queue is empty.
Fixed length queue.

34. Producers & Consumers

35. Question
Readers And Writers: A shared resource (database?) that allows multiple readers at the same time (read only), but only a single writer (and no readers).

36. Dining Philosophers Philosophers Eat/Think Each need 2 forks to eat.
Modern Operating Systems, 3rd ed., Andrew Tanenbuam 

37. Solution Part 1
Modern Operating Systems, 3rd ed., Andrew Tanenbuam 

38. Solution Part 2
Modern Operating Systems, 3rd ed., Andrew Tanenbuam 

39. Producers & Consumers

40. Question
Readers And Writers: A shared resource (database?) that allows multiple readers at the same time (read only), but only a single writer (and no readers).

41. Dining Philosophers Philosophers Eat/Think Each need 2 forks to eat.
Modern Operating Systems, 3rd ed., Andrew Tanenbuam 

42. Solution Part 1
Modern Operating Systems, 3rd ed., Andrew Tanenbuam 

43. Solution Part 2
Modern Operating Systems, 3rd ed., Andrew Tanenbuam 

44. Deadlocks

45. Deadlocks
A deadlock occurs when multiple processes are waiting on each other mutually blocking each other and thus will never run.
The most common approach to deadlocks is to do nothing.
However, in a nuclear power plant, airplane control systems, etc., ignoring deadlocks is not an option.

46. Deadlock detection
Allow deadlocks to happen but detect it when it does.
Periodically check for deadlock state.
Construct the wait-for-graph and kill one or more threads/processes that are deadlocked.

47. Deadlock Avoidance
Before granting requests for locks the Operating system checks if granting that request would move the system into an unsafe state.
An unsafe state occurs when there is the possibility of deadlock.
Dijkstra developed the bankers algorithm to achieve deadlock avoidance.

48. Deadlock Prevetion
Through enforceable locking policy, prevent deadlocks from happening.
If all of the resources can be enumerated, one policy can ensure that they most be requested in that order.
A thread that holds resource (e.g. lock) numbered ‘X’ can only request resources ‘Y’ > ‘X’.

49. Resources Examples of computer resources
printers
tape drives
tables
Processes need access to resources in reasonable order
Suppose a process holds resource A and requests resource B
at the same time another process holds B and requests A
both are blocked and remain so

50. Resources (1)‏ Deadlocks occur when … Preemptable resources
processes are granted exclusive access to “devices”
we refer to these devices generally resources
Preemptable resources
can be taken away from a process with no ill effects
Nonpreemptable resources
will cause the process to fail if taken away

51. Resources (2)‏ Sequence of events required to use a resource
request the resource
use the resource
release the resource
Must wait if request is denied
requesting process may be blocked
may fail with error code

52. Introduction to Deadlocks
Formal definition : A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause
Usually the event waited is release of a currently held resource
None of the processes can …
run
release resources
be awakened

53. Four Conditions for Deadlock
1. Mutual exclusion condition
each resource assigned to 1 process or is available
2. Hold and wait condition
process holding resources can request additional
3. No preemption condition
previously granted resources cannot forcibly taken away
4. Circular wait condition
must be a circular chain of 2 or more processes
each is waiting for resource held by next member of the chain

54. Deadlock Modeling (2)‏ Modeled with directed graphs
resource R assigned to process A
process B is requesting/waiting for resource S
process C and D are in deadlock over resources T and U

55. Deadlock Modeling (3)‏ Strategies for dealing with Deadlocks
just ignore the problem altogether
detection and recovery
dynamic avoidance
careful resource allocation
prevention
negating one of the four necessary conditions

56. Deadlock Modeling (4)‏
A B C
How deadlock occurs

57. How deadlock can be avoided
Deadlock Modeling (5)‏
(o) (p) (q)‏
How deadlock can be avoided

58. The Ostrich Algorithm Pretend there is no problem Reasonable if
deadlocks occur very rarely
cost of prevention is high
UNIX and Windows take this approach
It is a trade off between
convenience
correctness

59. Detection and Recovery
One resource of each type
Multiple resource of each type

60. Detection with One Resource of Each Type (1)‏
Note the resource ownership and requests
A cycle can be found within the graph, denoting deadlock

61. Detection with Multiple Resource of Each Type (1)‏
Data structures needed by deadlock detection algorithm

62. Detection with Multiple Resource of Each Type (2)‏
An example for the deadlock detection algorithm

63. Detecting Deadlock If any process is unmarked, it is in deadlock
Look for an unmarked process P, for which the i-th row of R is less then or equal to A.
Add the process P' row from C to A and mark the process.
Stopping criteria: step 1 fails
If any process is unmarked, it is in deadlock

64. Recovery from Deadlock (1)‏
Recovery through preemption
take a resource from some other process
depends on nature of the resource
Recovery through rollback (to a file)‏
checkpoint (memory image and resource state) of a process periodically.
use this saved state
restart the process if it is found deadlocked
Q: Overwrite checkpoints or not?

65. Recovery from Deadlock (2)‏
Recovery through killing processes
crudest but simplest way to break a deadlock
kill one of the processes in the deadlock cycle
the other processes get its resources
Which one to kill?
choose a process that can be rerun from the beginning

66. Deadlock Avoidance What was the assumption in deadlock detection?
Assumed that we know what resources processes would need prior to run (or all at once – not necessarily use them all at once!)
Q: Is there an algorithm that can always avoid deadlock by making the right choice all the time?

67. Safe and Unsafe States
Safe state: There exists a sequence of allocations that allows all processes to complete
Unsafe: opposite of safe

68. Deadlock Avoidance Resource Trajectories
Two process resource trajectories

69. Safe and Unsafe States
Safe state: not deadlocked and there is some scheduling order in which every process can run to completion even if all of them suddenly request their maximum number of resources immediately.
Unsafe state: OS can’t prevent deadlock. But itself is not a deadlock state.

70. (a) is safe: B->C->A
Safe and Unsafe States
Total number of resources: 10
(a) (b) (c) (d) (e)‏
(a) is safe: B->C->A

71. Safe and Unsafe States (2)‏
(a) (b) (c) (d)
Demonstration that the state in (b) is not safe:
A requests one more resulting (b)‏

72. Is Unsafe state a deadlock state?
Yes or no?
Then, can we have a scheduling algorithm that will give us a safe allocation sequence?

73. The Banker's Algorithm for a Single Resource
(a) (b) (c)‏
Three resource allocation states
safe
unsafe

74. Banker's Algorithm for Multiple Resources
E: Existing resources; P: Possessed resources;
A: Available resources (D->A->B->C)‏

75. Avoidance
Deadlock Avoidance is not realistic either since it requires future info.: max resources to be needed.

76. Deadlock Prevention
Set a policy in resource allocation so deadlock is not possible
I.e., attack one of the four conditions of deadlock.

77. Deadlock Prevention Attacking the Mutual Exclusion Condition
Some devices (such as printer) can be spooled
only the printer daemon uses printer resource
thus deadlock for printer eliminated
Not all devices can be spooled
Principle:
avoid assigning resource when not absolutely necessary
as few processes as possible actually claim the resource

78. Attacking the Hold and Wait Condition
Require processes to request resources before starting
a process never has to wait for what it needs
Problems
may not know required resources at start of run
also ties up resources other processes could be using
Variation:
process must give up all resources
then request all immediately needed

79. Attacking the No Preemption Condition
This is not a viable option
Consider a process given the printer
halfway through its job
now forcibly take away printer
!!??

80. Attacking the Circular Wait Condition (1)‏
(a) (b)‏
Process must request resources in their ordering. If you have 5, you may not request 1.

81. Summary of approaches to deadlock prevention

82. Other Issues Two-Phase Locking
Phase One
process tries to lock all records it needs, one at a time
if a needed record found locked, start over
(no real work done in phase one)‏
If phase one succeeds, it starts second phase,
performing updates
releasing locks
Note similarity to requesting all resources at once
Algorithm works where programmer can arrange
program can be stopped, restarted

83. Non-resource Deadlocks
Possible for two processes to deadlock
each is waiting for the other to do some task
Can happen with semaphores
each process required to do a down() on two semaphores (mutex and another)‏
if done in wrong order, deadlock results

84. Deadlock vs. Starvation
Four conditions necessary for deadlock
Four strategies for dealing with deadlock
Resource allocation graphs
Banker’s Algorithm
Safe vs. UnSafe vs. Deadlock
Deadlock recovery options
Policies for deadlock prevention (negation).