lecture 6. synchronization

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



Project 1 OutPartner sign-up!

• Approximately 3 students un-partnered• let's wrap this up today




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



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



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




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




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:

.

.

.

.

..

.

.

.

.

.

.




Stack holds function arguments, return address, localvariablesPermits recursive execution


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:

.

.

.

.

..

.

.

.

.

.

.




Stack holds function arguments, return address, local

variablesPermits recursive execution


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:

.

.

.

.

..

.

.

.

.

.

.







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:

.

.

.

.

..

.

.

.

.

.

.







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:

.

.

.

.

..

.

.

.

.

.

.







A(int tmp) {

if (tmp<2)

B();

printf(tmp);

}

B() {

C();

}

C() {

A(2);}

A(1);

exit;

StackPointer

Stack Growth

A: tmp=1


addrX:

addrY:

addrU:

addrV:

addrZ:

.

.

.

.

..

.

.

.

.

.

.







A(int tmp) {

if (tmp<2)

B();

printf(tmp);

}

B() {

C();

}

C() {

A(2);}

A(1);

exit;

StackPointer

Stack Growth

A: tmp=1


C: ret=addrU

addrX:

addrY:

addrU:

addrV:

addrZ:

.

.

.

.

..

.

.

.

.

.

.







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


C: ret=addrU

addrX:

addrY:

addrU:

addrV:

addrZ:

.

.

.

.

..

.

.

.

.

.

.




A(int tmp) {

if (tmp<2)

B();

printf(tmp);

}

B() {

C();

}

C() {

A(2);}

A(1);

exit;

StackPointer

Stack Growth

A: tmp=1


C: ret=addrU

addrX:

addrY:

addrU:

addrV:

addrZ:

.

.

.

.

..

.

.

.

.

.

.

Output:2




A(int tmp) {

if (tmp<2)

B();

printf(tmp);

}

B() {

C();

}

C() {

A(2);}

A(1);

exit;

StackPointer

Stack Growth

A: tmp=1


addrX:

addrY:

addrU:

addrV:

addrZ:

.

.

.

.

..

.

.

.

.

.

.

Output:2




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



(Old) Process Address Space




(New) Address Space with Threads All threads in a single process share the same addressspace!




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




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, …




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?




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);




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);




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 -= amount; balance= $1400 balance = get_balance(account); balance -= amount; balance= 1400 put_balance(account, balance);



d



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, …


h h h d



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




M l E l i



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;



M l E l i



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;


Thread 2 balance = get_balance(account);

balance -= amount;


Critical Region (Thread 2)


balance -= amount;

put_balance(account, balance); Operating Systems2013 - AAIT 34 of 32

M l E l i



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


Thread 2 balance = get_balance(account);

balance -= amount;


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



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


St t 1 Di bli I t t



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


St t g 2 L k



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.


U i g L k



Using Locks

int withdraw(account, amount) {acquire(lock);balance = get_balance(account); Critical Regionbalance -= amount;put_balance(account, balance);release(lock);return balance;

}




Execution with Locks



Execution with LocksProblem is that the internals of the lock acquire/releasehave critical sections too!


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?





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;


Context Switch

Thread 1 runs

Thread 2 runsContext Switch

Thread 1 Completes




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)


Spinlocks using test and set



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:


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



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.


Spinlocks using Interrupt Enable/Disable



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:


struct lock {/* No state*/

}void acquire(lock) {

disableInterrupts();}void release(lock) {

enableInterrupts();}

Spinlocks using Interrupt Enable/Disable:



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?”


Mutexes – Blocking Locks



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!









Limitations of locks



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.




Administrivia



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

lecture 6. synchronization

Documents