1. COP 4600 Operating Systems Spring 2011
Dan C. Marinescu
Office: HEC 304
Office hours: Tu-Th 5:00 – 6:00 PM

2. Lecture 19 – Thursday March 31, 2011
Last time:
Conditions for thread coordination – Safety, Liveness, Bounded-Wait, Fairness
Critical sections – a solution to critical section problem
Locks and Before-or-After actions. Hardware support for locks
Deadlocks; Signals; Semaphores; Monitors
Today:
Solutions to HW5
Thread coordination with a bounded buffer.
WAIT
NOTIFY
AWAIT
ADVANCE
SEQUENCE
TICKET
Scheduling Algorithms
Next Time
Multilevel memories
Lecture 19

3. A solution to critical section problem
Applies only to two threads Ti and Tj with i,j ={0,1} which share
integer turn  if turn=i then it is the turn of Ti to enter the critical section
boolean flag[2]  if flag[i]= TRUE then Ti is ready to enter the critical section
To enter the critical section thread Ti
sets flag[i]= TRUE
sets turn=j
If both threads want to enter then turn will end up with a value of either i or j and the corresponding thread will enter the critical section.
Ti enters the critical section - in other words leaves the while loop - only if either
flag[j]= FALSE Tj is not ready to enter or
turn=i  it is the turn of Ti to enter
The solution is correct
Mutual exclusion is guaranteed
The liveliness is ensured
The bounded-waiting is met
But this solution may not work as load and store instructions can be interrupted on modern computer architectures
Lecture 19

4. Lecture 19

5. Problem 5.3
Virtual address space  range of memory addresses a thread/process is allowed to access.
Each process runs in its own virtual address space.
The problem requires a basic understanding on how virtual addresses are translated into real addresses as we discussed in Lecture 15.
Lecture 19

6. Lecture 19

7. Lecture 19

8. Lecture 19

9. Problem 5.5
One writer rule  coordination is easier if each variable has only one writer.
Lecture 19

10. Bounded buffer Events and signals can be used for thread coordination.
The basic strategy:
Thread A issues WAIT(event)
Thread B issues a NOTIFY(event)
Lecture 19

11. Lecture 19

12. NOTIFY could be sent before the WAIT and this causes problems
The NOTIFY should always be sent after the WAIT. If the sender and the receiver run on two different processor there could be a race condition for the notempty event.
Tension between modularity and locks
Several possible solutions: AWAIT/ADVANCE, semaphores, etc
Lecture 19

13. Solution
We want a solution to prevent the unbounded wait when the NOTIFY(event) is sent before WAIT(event).
This solution eliminated the need for NOTIFY(event) but it requires
A shared variable for each event kept in kernel space
Adds to the state of a thread
the name of every event and
a count for that event
Two new system calls
AWAIT and
ADVANCE
Lecture 19

14. Lecture 19

15. AWAIT - ADVANCE
A WAITING state and two before-or-after actions that take a RUNNING thread into the WAITING state and back to RUNNABLE state.
eventcount  variables with an integer value shared between threads and the thread manager; they are like events but have a value.
The entry for a thread in the thread table must also include an event name and a value or count for that event for the thread.
A thread in the WAITING state waits for a particular value of the eventcount
AWAIT(eventcount,value)
If eventcount >value  the control is returned to the thread calling AWAIT and this thread will continue execution
If eventcount ≤value  the state of the thread calling AWAIT is changed to WAITING and the thread is suspended.
ADVANCE(eventcount)
increments the eventcount by one then
searches the thread_table for threads waiting for this eventcount
if it finds a thread and the eventcount exceeds the value the thread is waiting for then the state of the thread is changed to RUNNABLE
Lecture 19

16. Implementation of AWAIT and ADVANCE
Lecture 19

17. Lecture 19

18. Solution for a single sender and single receiver
Lecture 19

19. Multiple senders: the sequencer
Sequencer shared variable supporting thread sequence coordination -it allows threads to be ordered and is manipulated using two before-or-after actions.
TICKET(sequencer)  returns a negative value which increases by one at each call. Two concurrent threads calling TICKET on the same sequencer will receive different values based upon the timing of the call, the one calling first will receive a smaller value.
READ(sequencer)  returns the current value of the sequencer
Lecture 19

20. Multiple sender solution; only the SEND is modified
Lecture 19

21. Scheduling algorithms
Scheduling  assigning jobs to machines.
A schedule S  a plan on how to process N jobs using one or machines.
Scheduling in the general case in a NP complete problem.
A job 1 <= j <- N is characterized by
Ci S  completion time of job j under schedule S
pi  processing time
ri  release time; the time when the job is available for processing
di  due time ; the time when the job should be completed.
ui =0 if Ci S <= di and ui =1 otherwise
Lj = Ci S - di  lateness
A schedule S is characterized by
The makespan Cmax = max Ci S
Average completion time
Lecture 19