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

2. Lecture 17 – Thursday, March 24, 2011
Last time:
Threads
Thread state
Processor switching - YIELD system call
Today:
Processor switching
Communication with a bounded buffer
Next time
Semaphores
Deadlocks
Lecture 17

3. YIELD
System call  executed by the kernel at the request of an application
allows an active thread A to voluntarily release control of the processor.
YIELD invokes the ENTER_PROCESSOR_LAYER procedure
locks the thread table and unlock it when it finishes it work
changes the state of thread A from RUNNING to RUNNABLE
invokes the SCHEDULER
the SCHEDULER searches the thread table to find another tread B in RUNNABLE state
the state of thread B is changed from RUNNABLE to RUNNING
the registers of the processor are loaded with the ones saved on the stack for thread B
thread B becomes active
Why is it necessary to lock the thread table?
We may have multiple cores/processors so another thread my be active.
An interrupt may occur
The pseudo code assumes that we have a fixed number of threads, 7.
The flow of control
YIELDENTER_PROCESSOR_LAYERSCHEDULEREXIT_PROCESSOR_LAYERYIELD
Lecture 17

4. Lecture 17

5. Dynamic thread creation and termination
Until now we assumed a fixed number, 7 threads; the thread table was of fixed size.
We have to support two other system calls:
EXIT_THREAD Allow a tread to self-destroy and clean-up
DESTRY_THREAD  Allow a thread to terminate another thread of the same application
Lecture 17

6. Important facts to remember
Each thread has a unique ThreadId
Threads save their state on the stack.
The stack pointer of a thread is stored in the thread table.
To activate a thread the registers of the processor are loaded with information from the thread state.
What if no thread is able to run 
create a dummy thread for each processor called a processor_thread which is scheduled to run when no other thread is available
the processor_thread runs in the thread layer
the SCHEDULER runs in the processor layer
We have a processor thread for each processor/core.
Lecture 17

7. System start-up procedure
Procedure RUN_PROCESSORS() for each processor do allocate stack and setup processor thread /*allocation of the stack done at processor layer shutdown  FALSE SCHEDULER() deallocate processor_thread stack /*deallocation of the stack done at processor layer halt processor
Lecture 17

8. Switching threads with dynamic thread creation
Switching from one user thread to another requires two steps
Switch from the thread releasing the processor to the processor thread
Switch from the processor thread to the new thread which is going to have the control of the processor
The last step requires the SCHEDULER to circle through the thread_table until a thread ready to run is found
The boundary between user layer threads and processor layer thread is crossed twice
Example: switch from thread 0 to thread 6 using
YIELD
ENTER_PROCESSOR_LAYER
EXIT_PROCESSOR_LAYER
Lecture 17

9. Dynamic thread creation/destruction
As before, the control flow is not obvious as some of the procedures reload the stack pointer (SP)
When a procedure reloads the stack pointer then the place where it transfers control when it executes a return is the procedure whose SP was saved on the stack and was reloaded before the execution of the return.
ENTER_PROCESSOR_LAYER
Changes the state of the thread calling YIELD from RUNNING to RUNNABLE
Save the state of the procedure calling it , YIELD, on the stack
Loads the processors registers with the state of the processor thread, thus starting the SCHEDULER
EXIT_PROCESSOR_LAYER
Saves the state of processor thread into the corresponding PROCESSOR_TABLE and loads the state of the thread selected by the SCHEDULER to run (in our example of thread 6) in the processor’s registers
Loads the SP with the values saved by the ENTER_PROCESSOR_LAYER
Lecture 17

10. Lecture 17

11. Lecture 17

12. Lecture 17

13. Lecture 17

14. Thread coordination with bounded buffers
Bounded buffer the virtualization of a communication channel
Thread coordination
Locks for serialization
Bounded buffers for communication
Producer thread  writes data into the buffer
Consumer thread read data from the buffer
Basic assumptions:
We have only two threads
Threads proceed concurrently at independent speeds/rates
Bounded buffer – only N buffer cells
Messages are of fixed size and occupy only one buffer cell.
Spin lock 
a thread keeps checking a control variable/semaphore “until the light turns green.”
feasible only when the threads run on a different processors (how could otherwise give a chance to other threads?)
Lecture 17

15. Lecture 17

16. Implicit assumptions for the correctness of the implementation
One sending and one receiving thread. Only one thread updates each shared variable.
Sender and receiver threads run on different processors to allow spin locks
in and out are implemented as integers large enough so that they do not overflow (e.g., 64 bit integers)
The shared memory used for the buffer provides read/write coherence
The memory provides before-or-after atomicity for the shared variables in and out
The result of executing a statement becomes visible to all threads in program order. No compiler optimization supported
Lecture 17

17. In practice….. Threads run concurrently  Race conditions may occur
 data in the buffer may be overwritten
 a lock for the bounded buffer
the producer acquires the lock before writing
the consumer acquires the lock before reading
Lecture 17

18. Lecture 17

19. We have to avoid deadlocks
If a producer thread cannot write because the buffer is full it has to release the lock to allow the consumer thread to acquire the lock to read, otherwise we have a deadlock.
If a consumer thread cannot read because the there is no new item in the buffer it has to release the lock to allow the consumer thread to acquire the lock to write, otherwise we have a deadlock.
Lecture 17

20. Lecture 17

21. In practice…
We have to ensure atomicity of some operations, e.g., updating the pointers
Lecture 17

22. One more pitfall of the previous implementation of bounded buffer
If in and out are long integers (64 or 128 bit) then a load requires two registers, e.,g, R1 and R2.
int “ FFFFFFFF”
L R1,int /* R1 
L R2,int /* R2  FFFFFFFF
Race conditions could affect a load or a store of the long integer.
Lecture 17

23. Lecture 17

24. In practice the threads may run on the same system….
We cannot use spinlocks for a thread to wait until an event occurs.
That’s why we have spent time on YIELD…
Lecture 17

25. Lecture 17