CENG334 Introduction to Operating Systems

CENG334 Introduction to Operating Systems
18/02/08 CENG334 Introduction to Operating Systems Synchronization Topics: Synchronization problem Race conditions and Critical Sections Mutual exclusion Locks Spinlocks Mutexes Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: Some of the following slides are adapted from Matt Welsh, Harvard Univ.

Single and Multithreaded Processes
18/02/08 Single and Multithreaded Processes

18/02/08 Synchronization Threads cooperate in multithreaded programs in several ways: Access to shared state e.g., multiple threads accessing a memory cache in a Web server To coordinate their execution e.g., Pressing stop button on browser cancels download of current page “stop button thread” has to signal the “download thread” For correctness, we have to control this cooperation Must assume threads interleave executions arbitrarily and at different rates scheduling is not under application’s control We control cooperation using synchronization enables us to restrict the interleaving of executions

18/02/08 Shared Resources We’ll focus on coordinating access to shared resources Basic problem: Two concurrent threads are accessing a shared variable If the variable is read/modified/written by both threads, then access to the variable must be controlled Otherwise, unexpected results may occur We’ll look at: Mechanisms to control access to shared resources Low-level mechanisms: locks Higher level mechanisms: mutexes, semaphores, monitors, and condition variables Patterns for coordinating access to shared resources bounded buffer, producer-consumer, … This stuff is complicated and rife with pitfalls Details are important for completing assignments Expect questions on the midterm/final!

Shared Variable Example
18/02/08 Shared Variable Example Suppose we implement a function to withdraw money from a bank account: int withdraw(account, amount) { balance = get_balance(account); balance = balance - amount; put_balance(account, balance); return balance; } Now suppose that you and your friend share a bank account with a balance of TL What happens if you both go to separate ATM machines, and simultaneously withdraw TL from the account?

18/02/08 Example continued We represent the situation by creating a separate thread for each ATM user doing a withdrawal Both threads run on the same bank server system Thread Thread 2 What’s the problem with this? What are the possible balance values after each thread runs? int withdraw(account, amount) { balance = get_balance(account); balance -= amount; put_balance(account, balance); return balance; } int withdraw(account, amount) { balance = get_balance(account); balance -= amount; put_balance(account, balance); return balance; }

Interleaved Execution
18/02/08 Interleaved Execution The execution of the two threads can be interleaved Assume preemptive scheduling Each thread can context switch after each instruction We need to worry about the worst-case scenario! What’s the account balance after this sequence? And who's happier, the bank or you??? balance = get_balance(account); balance -= amount; Execution sequence as seen by CPU context switch balance = get_balance(account); balance -= amount; put_balance(account, balance); context switch put_balance(account, balance);

Interleaved Execution
18/02/08 Interleaved Execution The execution of the two threads can be interleaved Assume preemptive scheduling Each thread can context switch after each instruction We need to worry about the worst-case scenario! What’s the account balance after this sequence? And who's happier, the bank or you??? Balance = 1000TL balance = get_balance(account); balance -= amount; Local = 900TL Execution sequence as seen by CPU balance = get_balance(account); balance -= amount; put_balance(account, balance); Local = 900TL Balance = 900TL put_balance(account, balance); Balance = 900TL!

18/02/08 Race Conditions A race occurs when correctness of the program depends on one thread reaching point x before another thread reaches point y The problem is that two concurrent threads access a shared resource without any synchronization This is called a race condition The result of the concurrent access is non-deterministic Result depends on: Timing When context switches occurred Which thread ran at context switch What the threads were doing We need mechanisms for controlling access to shared resources in the face of concurrency This allows us to reason about the operation of programs Essentially, we want to re-introduce determinism into the thread's execution Synchronization is necessary for any shared data structure buffers, queues, lists, hash tables, …

Which resources are shared?
18/02/08 Which resources are shared? Local variables in a function are not shared They exist on the stack, and each thread has its own stack You can't safely pass a pointer from a local variable to another thread Why? Global variables are shared Stored in static data portion of the address space Accessible by any thread Dynamically-allocated data is shared Stored in the heap, accessible by any thread (Reserved for OS) Unshared Stack for thread 0 Stack for thread 1 Stack for thread 2 Shared Heap Uninitialized vars (BSS segment) Initialized vars (data segment) Code (text segment)

18/02/08 Mutual Exclusion We want to use mutual exclusion to synchronize access to shared resources Meaning: When only one thread can access a shared resource at a time. Code that uses mutual exclusion to synchronize its execution is called a critical section Only one thread at a time can execute code in the critical section All other threads are forced to wait on entry When one thread leaves the critical section, another can enter Critical Section Thread 1 (modify account balance) Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutual Exclusion We want to use mutual exclusion to synchronize access to shared resources Meaning: When only one thread can access a shared resource at a time. Code that uses mutual exclusion to synchronize its execution is called a critical section Only one thread at a time can execute code in the critical section All other threads are forced to wait on entry When one thread leaves the critical section, another can enter Critical Section Thread 2 Thread 1 (modify account balance) 2nd thread must wait for critical section to clear Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutual Exclusion We want to use mutual exclusion to synchronize access to shared resources Meaning: When only one thread can access a shared resource at a time. Code that uses mutual exclusion to synchronize its execution is called a critical section Only one thread at a time can execute code in the critical section All other threads are forced to wait on entry When one thread leaves the critical section, another can enter Critical Section Thread 2 Thread 1 (modify account balance) 2nd thread free to enter 1st thread leaves critical section Adapted from Matt Welsh’s (Harvard University) slides.

Critical Section Requirements
18/02/08 Critical Section Requirements Mutual exclusion At most one thread is currently executing in the critical section Progress If thread T1 is outside the critical section, then T1 cannot prevent T2 from entering the critical section Bounded waiting (no starvation) If thread T1 is waiting on the critical section, then T1 will eventually enter the critical section Assumes threads eventually leave critical sections Performance The overhead of entering and exiting the critical section is small with respect to the work being done within it Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Locks A lock is a object (in memory) that provides the following two operations: acquire( ): a thread calls this before entering a critical section May require waiting to enter the critical section release( ): a thread calls this after leaving a critical section Allows another thread to enter the critical section A call to acquire( ) must have a corresponding call to release( ) Between acquire( ) and release( ), the thread holds the lock acquire( ) does not return until the caller holds the lock At most one thread can hold a lock at a time (usually!) We'll talk about the exceptions later... What can happen if acquire( ) and release( ) calls are not paired? Adapted from Matt Welsh’s (Harvard University) slides.

Using Locks int withdraw(account, amount) { acquire(lock);
18/02/08 Using Locks int withdraw(account, amount) { acquire(lock); balance = get_balance(account); balance -= amount; put_balance(account, balance); release(lock); return balance; } critical section Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Execution with Locks acquire(lock); balance = get_balance(account); balance -= amount; put_balance(account, balance); release(lock); Thread 1 runs Thread 2 waits on lock Thread 1 completes Thread 2 resumes What happens when the blue thread tries to acquire the lock? Adapted from Matt Welsh’s (Harvard University) slides.

Spinlocks Very simple way to implement a lock: Why doesn't this work?
18/02/08 Spinlocks Very simple way to implement a lock: Why doesn't this work? Where is the race condition? struct lock { int held = 0; } void acquire(lock) { while (lock->held); lock->held = 1; void release(lock) { lock->held = 0; The caller busy waits for the lock to be released Adapted from Matt Welsh’s (Harvard University) slides.

Implementing Spinlocks
18/02/08 Implementing Spinlocks Problem is that the internals of the lock acquire/release have critical sections too! The acquire( ) and release( ) actions must be atomic Atomic means that the code cannot be interrupted during execution “All or nothing” execution struct lock { int held = 0; } void acquire(lock) { while (lock->held); lock->held = 1; void release(lock) { lock->held = 0; What can happen if there is a context switch here? Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Implementing Spinlocks Problem is that the internals of the lock acquire/release have critical sections too! The acquire( ) and release( ) actions must be atomic Atomic means that the code cannot be interrupted during execution “All or nothing” execution struct lock { int held = 0; } void acquire(lock) { while (lock->held); lock->held = 1; void release(lock) { lock->held = 0; This sequence needs to be atomic Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Implementing Spinlocks Problem is that the internals of the lock acquire/release have critical sections too! The acquire( ) and release( ) actions must be atomic Atomic means that the code cannot be interrupted during execution “All or nothing” execution Doing this requires help from hardware! Disabling interrupts Why does this prevent a context switch from occurring? Atomic instructions – CPU guarantees entire action will execute atomically Test-and-set Compare-and-swap Adapted from Matt Welsh’s (Harvard University) slides.

Spinlocks using test-and-set
18/02/08 Spinlocks using test-and-set CPU provides the following as one atomic instruction: So to fix our broken spinlocks, we do this: bool test_and_set(bool *flag) { … // Hardware dependent implementation } struct lock { int held = 0; } void acquire(lock) { while(test_and_set(&lock->held)); void release(lock) { lock->held = 0; Adapted from Matt Welsh’s (Harvard University) slides.

What's wrong with spinlocks?
18/02/08 What's wrong with spinlocks? OK, so spinlocks work (if you implement them correctly), and they are simple. So what's the catch? struct lock { int held = 0; } void acquire(lock) { while(test_and_set(&lock->held)); void release(lock) { lock->held = 0; Adapted from Matt Welsh’s (Harvard University) slides.

Problems with spinlocks
18/02/08 Problems with spinlocks Horribly wasteful! Threads waiting to acquire locks spin on the CPU Eats up lots of cycles, slows down progress of other threads Note that other threads can still run ... how? What happens if you have a lot of threads trying to acquire the lock? Only want spinlocks as primitives to build higher-level synchronization constructs Adapted from Matt Welsh’s (Harvard University) slides.

Disabling Interrupts An alternative to spinlocks:
18/02/08 Disabling Interrupts An alternative to spinlocks: Can two threads disable/reenable interrupts at the same time? What's wrong with this approach? struct lock { // Note – no state! } void acquire(lock) { cli(); // disable interrupts void release(lock) { sti(); // reenable interupts Adapted from Matt Welsh’s (Harvard University) slides.

Disabling Interrupts An alternative to spinlocks:
18/02/08 Disabling Interrupts An alternative to spinlocks: Can two threads disable/reenable interrupts at the same time? What's wrong with this approach? Can only be implemented at kernel level (why?) Inefficient on a multiprocessor system (why?) All locks in the system are mutually exclusive No separation between different locks for different bank accounts struct lock { // Note – no state! } void acquire(lock) { cli(); // disable interrupts void release(lock) { sti(); // reenable interupts Adapted from Matt Welsh’s (Harvard University) slides.

Peterson’s Algorithm flag[0] = 0; flag[1] = 0; turn; P0: flag[0] = 1;
18/02/08 Peterson’s Algorithm flag[0] = 0; flag[1] = 0; turn; P0: flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section …. // end of critical section flag[0] = 0; P1: flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section …. // end of critical section flag[1] = 0; The algorithm uses two variables, flag and turn. A flag value of 1 indicates that the process wants to enter the critical section. The variable turn holds the ID of the process whose turn it is. Entrance to the critical section is granted for process P0 if P1 does not want to enter its critical section or if P1 has given priority to P0 by setting turn to 0. Adapted from Matt Welsh’s (Harvard University) slides.

Mutexes – Blocking Locks
18/02/08 Mutexes – Blocking Locks Really want a thread waiting to enter a critical section to block Put the thread to sleep until it can enter the critical section Frees up the CPU for other threads to run Straightforward to implement using our TCB queues! ??? Thread 1 1) Check lock state unlocked Lock state Ø Lock wait queue Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutexes – Blocking Locks Really want a thread waiting to enter a critical section to block Put the thread to sleep until it can enter the critical section Frees up the CPU for other threads to run Straightforward to implement using our TCB queues! Thread 1 1) Check lock state 2) Set state to locked 3) Enter critical section locked Lock state Ø Lock wait queue Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutexes – Blocking Locks Really want a thread waiting to enter a critical section to block Put the thread to sleep until it can enter the critical section Frees up the CPU for other threads to run Straightforward to implement using our TCB queues! ??? Thread 2 Thread 1 1) Check lock state locked Lock state Ø Lock wait queue Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutexes – Blocking Locks Really want a thread waiting to enter a critical section to block Put the thread to sleep until it can enter the critical section Frees up the CPU for other threads to run Straightforward to implement using our TCB queues! Thread 2 Thread 1 1) Check lock state 2) Add self to wait queue (sleep) locked Lock state Thread 2 Ø Lock wait queue Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutexes – Blocking Locks Really want a thread waiting to enter a critical section to block Put the thread to sleep until it can enter the critical section Frees up the CPU for other threads to run Straightforward to implement using our TCB queues! ??? Thread 3 Thread 1 1) Check lock state 2) Add self to wait queue (sleep) locked Lock state Thread 2 Thread 3 Lock wait queue Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutexes – Blocking Locks Really want a thread waiting to enter a critical section to block Put the thread to sleep until it can enter the critical section Frees up the CPU for other threads to run Straightforward to implement using our TCB queues! Thread 1 1) Thread 1 finishes critical section locked Lock state Thread 2 Thread 3 Lock wait queue Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutexes – Blocking Locks Really want a thread waiting to enter a critical section to block Put the thread to sleep until it can enter the critical section Frees up the CPU for other threads to run Straightforward to implement using our TCB queues! Thread 3 Thread 1 1) Thread 1 finishes critical section 2) Reset lock state to unlocked 3) Wake one thread from wait queue unlocked Lock state Thread 2 Thread 3 Lock wait queue Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Mutexes – Blocking Locks Really want a thread waiting to enter a critical section to block Put the thread to sleep until it can enter the critical section Frees up the CPU for other threads to run Straightforward to implement using our TCB queues! Thread 3 Thread 3 can now grab lock and enter critical section locked Lock state Thread 2 Lock wait queue Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Limitations of locks Locks are great, and simple. What can they not easily accomplish? What if you have a data structure where it's OK for many threads to read the data, but only one thread to write the data? Bank account example. Locks only let one thread access the data structure at a time. Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Limitations of locks Locks are great, and simple. What can they not easily accomplish? What if you have a data structure where it's OK for many threads to read the data, but only one thread to write the data? Bank account example. Locks only let one thread access the data structure at a time. What if you want to protect access to two (or more) data structures at a time? e.g., Transferring money from one bank account to another. Simple approach: Use a separate lock for each. What happens if you have transfer from account A -> account B, at the same time as transfer from account B -> account A? Hmmmmm ... tricky. We will get into this next time. Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Now.. Higher level synchronization primitives: How do to fancier stuff than just locks Semaphores, monitors, and condition variables Implemented using basic locks as a primitive Allow applications to perform more complicated coordination schemes Adapted from Matt Welsh’s (Harvard University) slides. Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 CENG334 Introduction to Operating Systems Semaphores Topics: Need for higher-level synchronization primitives Semaphores and their implementation The Producer/Consumer problem and its solution with semaphores The Reader/Writer problem and its solution with semaphores Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: Some of the following slides are adapted from Matt Welsh, Harvard Univ.

Higher-level synchronization primitives
18/02/08 Higher-level synchronization primitives We have looked at one synchronization primitive: locks Locks are useful for many things, but sometimes programs have different requirements. Examples? Say we had a shared variable where we wanted any number of threads to read the variable, but only one thread to write it. How would you do this with locks? What's wrong with this code? Reader() { lock.acquire(); mycopy = shared_var; lock.release(); return mycopy; } Writer() { lock.acquire(); shared_var = NEW_VALUE; lock.release(); } Adapted from Matt Welsh’s (Harvard University) slides.

Semaphores Higher-level synchronization construct
18/02/08 Semaphores Higher-level synchronization construct Designed by Edsger Dijkstra in the 1960's, part of the THE operating system (classic stuff!) Semaphore is a shared counter Two operations on semaphores: P() or wait() or down() From Dutch “proeberen”, meaning “test” Atomic action: Wait for semaphore value to become > 0, then decrement it V() or signal() or up() From Dutch “verhogen”, meaning “increment” Increments semaphore value by 1. Semaphore Adapted from Matt Welsh’s (Harvard University) slides.

Semaphore Example Semaphores can be used to implement locks:
18/02/08 Semaphore Example Semaphores can be used to implement locks: A semaphore where the counter value is only 0 or 1 is called a binary semaphore. Semaphore my_semaphore = 1; // Initialize to nonzero int withdraw(account, amount) { down(my_semaphore); balance = get_balance(account); balance -= amount; put_balance(account, balance); up(my_semaphore); return balance; } critical section Adapted from Matt Welsh’s (Harvard University) slides.

Simple Semaphore Implementation
18/02/08 Simple Semaphore Implementation struct semaphore { int val; threadlist L; // List of threads waiting for semaphore } down(semaphore S): // Wait until > 0 then decrement if (S.val <= 0) { add this thread to S.L; block(this thread); S.val = S.val -1; return; up(semaphore S): // Increment value and wake up next thread S.val = S.val + 1; if (S.L is nonempty) { remove a thread T from S.L; wakeup(T); What's wrong with this picture??? Adapted from Matt Welsh’s (Harvard University) slides.

Simple Semaphore Implementation
18/02/08 Simple Semaphore Implementation struct semaphore { int val; threadlist L; // List of threads waiting for semaphore } down(semaphore S): // Wait until > 0 then decrement while (S.val <= 0) { add this thread to S.L; block(this thread); S.val = S.val -1; return; up(semaphore S): // Increment value and wake up next thread S.val = S.val + 1; if (S.L is nonempty) { remove a thread T from S.L; wakeup(T); down() and up() must be atomic actions! Adapted from Matt Welsh’s (Harvard University) slides.

Semaphore Implementation
18/02/08 Semaphore Implementation How do we ensure that the semaphore implementation is atomic? Adapted from Matt Welsh’s (Harvard University) slides.

Semaphore Implementation
18/02/08 Semaphore Implementation How do we ensure that the semaphore implementation is atomic? One approach: Make them system calls, and ensure only one down() or up() operation can be executed by any process at a time. This effectively puts a lock around the down() and up() operations themselves! Easy to do by disabling interrupts in the down() and up() calls. Another approach: Use hardware support Say your CPU had atomic down and up instructions Adapted from Matt Welsh’s (Harvard University) slides.

OK, but why are semaphores useful?
18/02/08 OK, but why are semaphores useful? A binary semaphore (counter is always 0 or 1) is basically a lock. The real value of semaphores becomes apparent when the counter can be initialized to a value other than 0 or 1. Say we initialize a semaphore's counter to 50. What does this mean about down() and up() operations? Adapted from Matt Welsh’s (Harvard University) slides.

The Producer/Consumer Problem
18/02/08 The Producer/Consumer Problem Also called the Bounded Buffer problem. Producer pushes items into the buffer. Consumer pulls items from the buffer. Producer needs to wait when buffer is full. Consumer needs to wait when the buffer is empty. Mmmm... donuts Producer Consumer Adapted from Matt Welsh’s (Harvard University) slides.

The Producer/Consumer Problem
18/02/08 The Producer/Consumer Problem Also called the Bounded Buffer problem. Producer pushes items into the buffer. Consumer pulls items from the buffer. Producer needs to wait when buffer is full. Consumer needs to wait when the buffer is empty. zzzzz.... Producer Consumer Adapted from Matt Welsh’s (Harvard University) slides.

One implementation... Producer Consumer What's wrong with this code?
18/02/08 One implementation... Producer Consumer int count = 0; Producer() { int item; while (TRUE) { item = bake(); if (count == N) sleep(); insert_item(item); count = count + 1; if (count == 1) wakeup(consumer); } Consumer() { int item; while (TRUE) { if (count == 0) sleep(); item = remove_item(); count = count – 1; if (count == N-1) wakeup(producer); eat(item); } What if we context switch right here?? What's wrong with this code? Adapted from Matt Welsh’s (Harvard University) slides.

A fix using semaphores Producer Consumer Semaphore mutex = 1;
18/02/08 A fix using semaphores Producer Consumer Semaphore mutex = 1; Semaphore empty = N; Semaphore full = 0; Producer() { int item; while (TRUE) { item = bake(); down(empty); down(mutex); insert_item(item); up(mutex); up(full); } Consumer() { int item; while (TRUE) { down(full); down(mutex); item = remove_item(); up(mutex); up(empty); eat(item); } Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 Reader/Writers Let's go back to the problem at the beginning of lecture. Single shared object Want to allow any number of threads to read simultaneously But, only one thread should be able to write to the object at a time (And, not interfere with any readers...) Why the test here?? Semaphore mutex = 1; Semaphore wrt = 1; int readcount = 0; Writer() { down(wrt); do_write(); up(wrt); } Reader() { down(mutex); readcount++; if (readcount == 1) { down(wrt); } up(mutex); do_read(); readcount--; if (readcount == 0) { up(wrt); A Reader should only wait for a Writer to complete its do_write(). A Reader should not wait for other Readers to complete their do_read(). The Writer should wait for the other Writers to complete their do_write(). The Writer should wait for all the Readers to complete their do_read(). Adapted from Matt Welsh’s (Harvard University) slides.

Issues with Semaphores
18/02/08 Issues with Semaphores Much of the power of semaphores derives from calls to down() and up() that are unmatched See previous example! Unlike locks, acquire() and release() are not always paired. This means it is a lot easier to get into trouble with semaphores. “More rope” Would be nice if we had some clean, well-defined language support for synchronization... Java does! Adapted from Matt Welsh’s (Harvard University) slides.

18/02/08 CENG334 Introduction to Operating Systems Synchronization patterns Topics Signalling Rendezvous Barrier Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:

18/02/08 Signalling Possibly the simplest use for a semaphore is signaling, which means that one thread sends a signal to another thread to indicate that something has happened. Signaling makes it possible to guarantee that a section of code in one thread will run before a section of code in another thread; in other words, it solves the serialization problem. Adapted from The Little Book of Semaphores.

18/02/08 Signalling Imagine that a1 reads a line from a file, and b1 displays the line on the screen. The semaphore in this program guarantees that Thread A has completed a1 before Thread B begins b1. Here’s how it works: if thread B gets to the wait statement first, it will find the initial value, zero, and it will block. Then when Thread A signals, Thread B proceeds. Similarly, if Thread A gets to the signal first then the value of the semaphore will be incremented, and when Thread B gets to the wait, it will proceed immediately. Either way, the order of a1 and b1 is guaranteed. semaphore sem=0; Thread A statement a1; sem.up(); Thread B sem.down(); statement b1; Adapted from The Little Book of Semaphores.

18/02/08 Rendezvous Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a1 happens before b2 and b1 happens before a2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a1 and b1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Thread A statement a1; statement a2; Thread B statement b1; statement b2; Adapted from The Little Book of Semaphores.

18/02/08 Rendezvous - Hint Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a1 happens before b2 and b1 happens before a2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a1 and b1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Hint: Create two semaphores, named aArrived and bArrived, and initialize them both to zero. aArrived indicates whether Thread A has arrived at the rendezvous, and bArrived likewise. semaphore aArrived=0; semaphore bArrived=0; Thread A statement a1; statement a2; Thread B statement b1; statement b2; Adapted from The Little Book of Semaphores.

18/02/08 Rendezvous - Solution Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a1 happens before b2 and b1 happens before a2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a1 and b1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Hint: Create two semaphores, named aArrived and bArrived, and initialize them both to zero. aArrived indicates whether Thread A has arrived at the rendezvous, and bArrived likewise. semaphore aArrived=0; semaphore bArrived=0; Thread A statement a1; aArrived.up(); bArrived.down(); statement a2; Thread B statement b1; bArrived.up(); aArrived.down(); statement b2; Adapted from The Little Book of Semaphores.

Rendezvous – A less efficient solution
18/02/08 Rendezvous – A less efficient solution This solution also works, although it is probably less efficient, since it might have to switch between A and B one time more than necessary. If A arrives first, it waits for B. When B arrives, it wakes A and might proceed immediately to its wait in which case it blocks, allowing A to reach its signal, after which both threads can proceed.. semaphore aArrived=0; semaphore bArrived=0; Thread A statement a1 bArrived.down()‏ aArrived.up()‏ statement a2 Thread B statement b1; bArrived.up(); aArrived.down(); statement b2; Adapted from The Little Book of Semaphores.

Rendezvous – How about? semaphore aArrived=0; semaphore bArrived=0;
18/02/08 Rendezvous – How about? semaphore aArrived=0; semaphore bArrived=0; Thread A statement a1 bArrived.down()‏ aArrived.up()‏ statement a2 Thread B statement b1; aArrived.down(); bArrived.up(); statement b2; Adapted from The Little Book of Semaphores.

Barrier Rendezvous solution does not work with more than two threads.
18/02/08 Barrier Rendezvous solution does not work with more than two threads. Puzzle: Generalize the rendezvous solution. Every thread should run the following code: rendezvous(); criticalpoint(); The synchronization requirement is that no thread executes critical point until after all threads have executed rendezvous. You can assume that there are n threads and that this value is stored in a variable, n, that is accessible from all threads. When the first n − 1 threads arrive they should block until the nth thread arrives, at which point all the threads may proceed. Adapted from The Little Book of Semaphores.

18/02/08 Barrier - Hint n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; count keeps track of how many threads have arrived. mutex provides exclusive access to count so that threads can increment it safely. barrier is locked (zero or negative) until all threads arrive; then it should be unlocked (1 or more). Adapted from The Little Book of Semaphores.

What is wrong with this solution?
18/02/08 Barrier – Solution? n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex.down(); count = count + 1; mutex.up(); if (count == n) barrier.up(); else barrier.down(); Criticalpoint(); Since count is protected by a mutex, it counts the number of threads that pass. The first n−1 threads wait when they get to the barrier, which is initially locked. When the nth thread arrives, it unlocks the barrier. What is wrong with this solution? Adapted from The Little Book of Semaphores.

18/02/08 Barrier – Solution? n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex.down(); count = count + 1; mutex.up(); if (count == n) barrier.up(); else barrier.down(); Criticalpoint(); Imagine that n = 5 and that 4 threads are waiting at the barrier. The value of the semaphore is the number of threads in queue, negated, which is -4. When the 5th thread signals the barrier, one of the waiting threads is allowed to proceed, and the semaphore is incremented to -3. But then no one signals the semaphore again and none of the other threads can pass the barrier. Adapted from The Little Book of Semaphores.

18/02/08 Barrier – Solution n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex.down(); count = count + 1; mutex.up(); if (count == n) barrier.up(); else{ barrier.down(); barrier.up(); } Criticalpoint(); The only change is another signal after waiting at the barrier. Now as each thread passes, it signals the semaphore so that the next thread can pass. Adapted from The Little Book of Semaphores.

18/02/08 Barrier – Bad Solution n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex.down(); count = count + 1; if (count == n) barrier.up(); barrier.down(); barrier.up(); mutex.up(); Criticalpoint(); Imagine that the first thread enters the mutex and then blocks. Since the mutex is locked, no other threads can enter, so the condition, count==n, will never be true and no one will ever unlock. Adapted from The Little Book of Semaphores.

CENG334 Introduction to Operating Systems

Similar presentations

Presentation on theme: "CENG334 Introduction to Operating Systems"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CENG334 Introduction to Operating Systems

Similar presentations

Presentation on theme: "CENG334 Introduction to Operating Systems"— Presentation transcript:

Similar presentations

About project

Feedback