8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 1/59
ITSE 4931: Operating Systems
Lisanu [email protected]
Lecture 5: SynchronizationNov 05, 2013
Operating Systems2013 - AAIT 1 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 2/59
Project 1 OutPartner sign-up!
• Approximately 3 students un-partnered• let's wrap this up today
Operating Systems2013 - AAIT 2 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 3/59
Concurrent ProgrammingMany programs want to do many things “at once”
• Web browser:• Download web pages, and accept user input simultaneously
• Web server:• Handle incoming connections from multiple clients at once
• Applications with a Graphical User Interface. E.g. chess
• One thread does the displaying the current game on the screen• Another thread responds to user inputs
• A third one, figuring out which move to make next
In each case, would like to share memory across these
activities• Web browser: Share buffer for HTML page and inlined images• Web server: Share memory cache of recently-accessed pages• Scientific programs: Share memory of data set being processes
Can't we simply do this with multiple processes?2013 - AAIT 3 of 39Operating Systems
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 4/59
Putting it together: Processes
…
Process 1 Process 2 Process N
CPUsched.
OS
CPU(1 core)
1 processat a time
CPU
state
IOstate
Mem.
CPU
state
IOstate
Mem.
CPU
state
IOstate
Mem.
2013 - AAIT 4 of 39Operating Systems
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 5/59
Putting it together: Process
Memory
I/O State(e.g., file,socketcontexts)
CPU state(PC, SP,registers..)
Sequentialstream ofinstructions
A(int tmp) {if (tmp<2)
B();
printf(tmp);}B() {
C();}
C() {
A(2);
}A(1);…
(Unix) Process
ResourcesStack
Stored in OS
2013 - AAIT 5 of 39Operating Systems
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 6/59
Putting it together: Threads
Process 1 Process N
CPUsched.
OS
CPU
IOstate
Mem.
…
threads
IOstate
Mem.
…
threads
… CPUstat
e
CPUstat
e
CPUstat
e
CPUstat
e
2013 - AAIT 6 of 39Operating Systems
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 7/59
Review: Execution Stack Example
Stack holds function arguments, return address, localvariablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
addrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 8/59
Review: Execution Stack Example
Stack holds function arguments, return address, localvariablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZaddrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 9/59
Review: Execution Stack Example
Stack holds function arguments, return address, local
variablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZaddrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 10/59
Review: Execution Stack Example
Stack holds function arguments, return address, local
variablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZaddrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 11/59
Review: Execution Stack Example
Stack holds function arguments, return address, local
variablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZB: ret=addrY
addrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 12/59
Review: Execution Stack Example
Stack holds function arguments, return address, local
variablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZB: ret=addrY
addrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 13/59
Review: Execution Stack Example
Stack holds function arguments, return address, local
variablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZB: ret=addrY
C: ret=addrU
addrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 14/59
Review: Execution Stack Example
Stack holds function arguments, return address, local
variablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZB: ret=addrY
C: ret=addrU
addrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 15/59
Review: Execution Stack Example
Stack holds function arguments, return address, local
variablesPermits recursive execution
Crucial to modern languages
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
A: tmp=2
ret=addrVStackPointer
Stack Growth
A: tmp=1
ret=addrZB: ret=addrY
C: ret=addrU
addrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 16/59
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 17/59
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 18/59
Review: Execution Stack Example
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZB: ret=addrY
C: ret=addrU
addrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
Output:2
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 19/59
Review: Execution Stack Example
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1
ret=addrZB: ret=addrY
addrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
Output:2
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 20/59
Review: Execution Stack Example
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
}
B() {
C();
}
C() {
A(2);}
A(1);
exit;
StackPointer
Stack Growth
A: tmp=1ret=addrZaddrX:
addrY:
addrU:
addrV:
addrZ:
.
.
.
.
..
.
.
.
.
.
.
Output:21
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 21/59
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 22/59
(Old) Process Address Space
2013 - AAIT 22 of 39Operating Systems
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 23/59
(New) Address Space with Threads All threads in a single process share the same addressspace!
2013 - AAIT 23 of 39Operating Systems
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 24/59
SynchronizationThreads cooperate in multithreaded programs in severalways:
Access to shared address space (Code and Data)• 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 cooperationMust assume that threads can interleave executionsarbitrarily and at run at different rates
• One process may only partially complete execution• Our goal: to control thread cooperation using synchronization.
• enables us to restrict the interleaving of executions
Operating Systems2013 - AAIT 24 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 25/59
Shared ResourcesWe’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
Over the next two lectures, we’ll look at: • Mechanisms to control access to shared resources
• Low-level mechanisms: locks
• Higher level mechanisms: mutexes, semaphores, monitors, andcondition variables
• Patterns for coordinating access to shared resources• bounded buffer, producer- consumer, …
Operating Systems2013 - AAIT 25 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 26/59
Shared Variable ExampleSuppose we implement a function to withdraw moneyfrom a bank account:int withdraw(account, amount) {
int balance = get_balance(account); /*Involves disk I/O*/balance = balance - amount;put_balance(account, balance); /*Involves disk I/O*/return balance;
}
Now suppose that you and your roommate share a bankaccount with balance of $1500.00
• What happens if you both go to separate ATM machines, andsimultaneously withdraw $100.00 from the account?
Operating Systems2013 - AAIT 26 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 27/59
Example continuedWe represent the situation by creating a separate threadfor each ATM user doing a withdrawal
• Both threads run on the same bank server system
Remember that processing can be interleaved• The processor can stop executing one thread and go to the other
at any point in the sequence of instructions• This is called “Preemptive scheduling”
Thread 1balance = get_balance(account);balance -= amount;put_balance(account, balance);
Thread 2balance = get_balance(account);balance -= amount;put_balance(account, balance);
Operating Systems2013 - AAIT 27 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 28/59
Example continuedExecution sequence as seen by CPU
Context SwitchExecution
Context Switch
What’s the account balance after this sequence? • And who's happier, the bank or you???
balance = get_balance(account);
balance -= amount;
balance = get_balance(account); balance -= amount; put_balance(account, balance);
put_balance(account, balance);
Operating Systems2013 - AAIT 28 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 29/59
Example continuedExecution sequence as seen by CPU
balance = $1500
Execution
balance = $1400 balance = $1400
What’s the account balance after this sequence? • You withdrew 200$ so the balance should have been 1300$ but it
is 1400$• And who's happier, the bank or you???
balance = get_balance(account);
balance -= amount; balance= $1400 balance = get_balance(account); balance -= amount; balance= 1400 put_balance(account, balance);
put_balance(account, balance);
Operating Systems2013 - AAIT 29 of 32
d
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 30/59
Race ConditionsThe problem is that two concurrent threads access ashared resource without any synchronization.
• This is called a r a c e c o n d i t i o n
• The result of the concurrent access is non-deterministic (involvingarbitrary choices)
• Result depends on:• The particular order in which the access takes place
• When context switches occurred
We need mechanisms for controlling access to sharedresources in the face of concurrency
• We want to re-introduce determinism into the thread's execution
Synchronization is necessary for any shared datastructure
• Buffers, queues, lists, hash tables, …
Operating Systems2013 - AAIT 30 of 32
h h h d
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 31/59
Which resources are shared?Local variables in a function are not shared
• They exist on the stack, and each thread has its own stack
Global variables are shared• Stored in static data portion of the addressspace• Accessible by any thread
Dynamically-allocated data is shared• Stored in the heap, accessible byany thread
Operating Systems2013 - AAIT 31 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 32/59
M l E l i
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 33/59
Mutual ExclusionWe want to use mutual exclusion to synchronize accessto shared resources
• Meaning: When only one thread can access a shared resource at atime.
Code that uses mutual exclusion to synchronize itsexecution is called a critical section
• The thread may be changing common variables, updating a table,writing a file, and so on
Critical Region (modify balance)
balance = get_balance(account); balance -= amount;
put_balance(account, balance);
Operating Systems2013 - AAIT 33 of 32
M l E l i
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 34/59
Mutual ExclusionOnly one thread at a time can execute code in the criticalsection
All other threads are forced to wait on entry
When one thread leaves the critical section, another canenter
Critical Region (Thread 1) balance = get_balance(account);
balance -= amount;
put_balance(account, balance);
Thread 2 balance = get_balance(account);
balance -= amount;
put_balance(account, balance);
Critical Region (Thread 2)
balance = get_balance(account);
balance -= amount;
put_balance(account, balance); Operating Systems2013 - AAIT 34 of 32
M l E l i
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 35/59
Mutual ExclusionOnly one thread at a time can execute code in the criticalsection
All other threads are forced to wait on entry
When one thread leaves the critical section, another canenter
Critical Region (Thread 1) balance = get_balance(account); balance=1500
balance -= amount; balance=1400
put_balance(account, balance);
Thread 2 balance = get_balance(account);
balance -= amount;
put_balance(account, balance);
Critical Region (Thread 2)
balance = get_balance(account); balance=1400
balance -= amount; balance=1300
put_balance(account, balance); Operating Systems2013 - AAIT 35 of 32
C iti l S ti R i t
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 36/59
Critical Section RequirementsMutual 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 eventuallyenter 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
Operating Systems2013 - AAIT 36 of 32
St t 1 Di bli I t t
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 37/59
Strategy 1: Disabling InterruptsContext switching takes place when Timer or anotherinterrupt occurs
• Disable all interrupts after entering critical region and re-enablethem just before leaving• Thread would be allowed to execute with out preemption.
What's wrong with this approach?
• It is unwise to give user processes the power to turn off interrupts• Suppose that one of them did it and never turned them on again
• Inefficient on a multiprocessor system• Disabling interrupts affects only the CPU that executed the disable
instruction
But, Convenient for the kernel itself to disable interruptsfor a few instructions
• E.g. An interrupt may occur while the list of ready processes wasbeing updated
Operating Systems2013 - AAIT 37 of 32
St t g 2 L k
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 38/59
Strategy 2: LocksIs a software solution
A lock is a shared variable (in memory), initially 1 (0means no process is in its critical region)
• To enter critical region: acquire() lock• If lock is 1, Set the lock to 0 and enter critical region
• If lock is 0, wait until it becomes 1
• To exit critical region: call release():• Set lock to 1
A call to acquire( ) must have a corresponding call torelease( )
• Between acquire( ) and release( ), the thread holds the lockWhat can happen if one thread sets lock to 1 and neversets it to 0
• No other process (thread) can enter its critical region.
Operating Systems2013 - AAIT 38 of 32
U i g L k
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 39/59
Using Locks
int withdraw(account, amount) {acquire(lock);balance = get_balance(account); Critical Regionbalance -= amount;put_balance(account, balance);release(lock);return balance;
}
Operating Systems2013 - AAIT 39 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 40/59
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 41/59
Execution with Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 42/59
Execution with LocksProblem is that the internals of the lock acquire/releasehave critical sections too!
Operating Systems2013 - AAIT 42 of 32
struct lock {
int available = 1;}void acquire(lock) {
while (! (lock-> available)); /* busy wait */lock-> available = 0;
}
void release(lock) {lock-> available = 1;}
What if there is acontext switch here?
Execution with Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 43/59
Execution with Locks
Otherwise two threads could think that they both have lockThis means both threads are in their critical regions at thesame time.
• This was what we were trying to avoid!!!!
Problem is that the internals of the acquiring a lock can’t beperformed in one instruction
• Needs to be a critical section - “All or nothing” execution• There shouldn’t be an interruption between testing and setting the
lock
while (!(lock -> available)); /*finds out that lock is 1*/
while (!(lock -> available)); /*finds out that lock is 1*/lock-> available = 0;
lock-> available = 0;
Operating Systems2013 - AAIT 43 of 32
Context Switch
Thread 1 runs
Thread 2 runsContext Switch
Thread 1 Completes
Execution with Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 44/59
Execution with LocksProblem is that the internals of the lock acquire/releasehave 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 executeatomically
• Test-and-set
• Compare-and-swap (Not discussed here; Read Operating SystemConcepts 5.4)
Operating Systems2013 - AAIT 44 of 32
Spinlocks using test and set
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 45/59
Spinlocks using test-and-setCPU provides the following as one atomic instruction:
• Reading locks value and storing are indivisible
So to fix our broken spinlocks, we do this:
Operating Systems2013 - AAIT 45 of 32
bool test_and_set(bool *flag) {bool old = *flag;*flag = 0;return old;
}
struct lock {int available = 1;
}void acquire(lock) {
while (! test_and_set (lock-> available)); /* busy wait */
}void release(lock) {
lock-> available = 1;
}
Change flag tounavailable (0)
Return old fag
• If lock is free, test&set reads1 and sets value=0, so lock isnow busy. It returns 1 sowhile exits
• If lock is busy, test&set reads0 and sets value=0 (nochange). It returns 0, so whileloop continues
• When we set value = 1,
someone else can get lock
Spinlocks using test and set: Problem
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 46/59
Spinlocks using test-and-set: ProblemOK, so spinlocks work, and they are simple.
Problem with busy waiting using spin locks and TSL• Threads waiting to acquire locks spin on the CPU.
• Threads waiting for a lock make the CPU execute their “lock checkingwhile” loop until they acquire it.
• This approach waste CPU time• The CPU could have executed other instructions.
• Priority Inversion: If busy-waiting thread has higher priority thanthread holding lock no progress!
What we need is a mechanism that blocks a thread (or aprocess) not make it wait.
Operating Systems2013 - AAIT 46 of 32
Spinlocks using Interrupt Enable/Disable
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 47/59
Spinlocks using Interrupt Enable/DisableCPU provides the following as one atomic instruction:
• How can we build multi-instruction atomic operations?• Recall: dispatcher gets when timer interrupt occurs.
• On a uniprocessor, can avoid context-switching by:• Preventing external events by disabling interrupts
So to fix our broken spinlocks, we do this:
Operating Systems2013 - AAIT 47 of 32
struct lock {/* No state*/
}void acquire(lock) {
disableInterrupts();}void release(lock) {
enableInterrupts();}
Spinlocks using Interrupt Enable/Disable:
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 48/59
Spinlocks using Interrupt Enable/Disable:Problems
Can’t let user do this! Consider following:acquire(lock) ;
while(TRUE) {;}
Real-Time system —no guarantees on timing!• Critical Sections might be arbitrarily long
What happens with I/O or other important events?• “Reactor about to meltdown. Help?”
Operating Systems2013 - AAIT 48 of 32
Mutexes – Blocking Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 49/59
Mutexes Blocking LocksReally want a thread waiting to enter a critical section toblock
• 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!
Operating Systems2013 - AAIT 49 of 32
Mutexes – Blocking Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 50/59
Mutexes Blocking LocksReally want a thread waiting to enter a critical section toblock
• 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!
Operating Systems2013 - AAIT 50 of 32
Mutexes – Blocking Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 51/59
Mutexes Blocking LocksReally want a thread waiting to enter a critical section toblock
• 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!
Operating Systems2013 - AAIT 51 of 32
Mutexes – Blocking Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 52/59
Mutexes Blocking LocksReally want a thread waiting to enter a critical section toblock
• 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!
Operating Systems2013 - AAIT 52 of 32
Mutexes – Blocking Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 53/59
Mutexes Blocking LocksReally want a thread waiting to enter a critical section toblock
• 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!
Operating Systems2013 - AAIT 53 of 32
Mutexes – Blocking Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 54/59
Mutexes Blocking LocksReally want a thread waiting to enter a critical section toblock
• 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!
Operating Systems2013 - AAIT 54 of 32
Mutexes – Blocking Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 55/59
Mutexes Blocking LocksReally want a thread waiting to enter a critical section toblock
• 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!
Operating Systems2013 - AAIT 55 of 32
Mutexes – Blocking Locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 56/59
Mutexes Blocking LocksReally want a thread waiting to enter a critical section toblock
• 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!
Operating Systems2013 - AAIT 56 of 32
Limitations of locks
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 57/59
Limitations of locksLocks are great, and simple. What can they not easilyaccomplish?
What if you have a data structure where it's OK for manythread so read the data, but only one thread to write thedata?
• Bank account example.• Locks only let one thread access the data structure at a time.
Operating Systems2013 - AAIT 57 of 32
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 58/59
Administrivia
8/10/2019 Lecture 6. Synchronization
http://slidepdf.com/reader/full/lecture-6-synchronization 59/59
AdministriviaNext Lecture:
Higher level synchronization primitives: How do tofancier stuff than just locks
Semaphores, monitors, and condition variables• Implemented using basic locks as a primitive
Allow applications to perform more complicatedcoordination schemes
Read Siberschatz Ch 5.1 – 5.5