Download pdf - Operating Systems - Synchronisation€¦ · Operating Systems Synchronisation Stephan Sigg Distributed and Ubiquitous Systems Technische Universit at Braunschweig February 10, 2011

Operating SystemsSynchronisation

Stephan Sigg

Distributed and Ubiquitous SystemsTechnische Universität Braunschweig

February 10, 2011

Stephan Sigg Operating Systems 1/79

Overview and Structure

Introduction to operating systemsHistoryArchitectures

ProcessesProcesses, Threads, IPC, SchedulingSynchronisationDeadlocks

Memory managementPagingSegmentation

Filesystems

Security and Protection

Distributed systems

Cryptography


OutlineSynchronisation

1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions


SynchronisationIntroduction

Definition

A cooperating process is one that can affect or be affected byother processes executing in the system

Cooperating processes can either directly share a logicaladdress space (code and data)

Or share data through files or messages

Concurrent access to shared data may result in datainconsistency



The producer-consumer-problem

Example

T0 : producer execute register1 = counter {register1 = 5}T1 : producer execute register1 = register1 + 1 {register1 = 6}T2 : consumer execute register2 = counter {register2 = 5}T3 : consumer execute register2 = register2 − 1 {register2 = 4}T4 : producer execute counter = register1 {counter = 6}T5 : consumer execute counter = register2 {counter = 4}



The producer-consumer-problem

Definition

A situation where processes access and manipulate the same dataconcurrently and the outcome of the execution depends on theorder in which access takes place is called a race condition

To guard against race condition we need to ensure that onlyone process at a time can be manipulating the shared data.

Synchronisation among processes is required


SynchronisationThe critical section problem

The critical section problem

Consider a system of n processes {P0,P1, . . . ,Pn−1}Each process has a segment of code called its critical section

In the critical section, processes change common variables,update a table, write a file, . . .

Only one process is allowed to execute its critical section at atime

The critical section problem is to design a protocol thatenables this property



The critical section problem

Structure of a typical process Pi :

1: while true do2: entry section3: critical section4: exit section5: remainder section6: end while

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection



A solution to the critical sectionproblem must satisfy the followingrequirements:

Mutual exclusion

Progress

Bounded waiting

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection



Mutual exclusion

If process Pi is executed in itscritical section, no otherprocesses are allowed to beexecuted in their critical sections

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection



Progress

If no process is executing in itscritical section

Only those processes that arenot executing in their remaindersection participate in decidingwether to enter the criticalsection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection



Bounded waiting

It exists a bound on the numberof times that other processes areallowed to enter their criticalsection after a request to enterthe critical section of a specificprocess is answered.

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection



Peterson’s solution

A software solution

Synchronisation of two processes Piand Pj

The processes share the two dataitems

int turn;boolean flag[2];

Process A

Kernel

Process B

turnflag[2]



Peterson’s solution

Structure of process Pi

1: while (true) do2: flag [i ] = true;3: turn = j ;4: while (flag [j ]&&turn == j) do5: nothing6: end while7: critical section8: flag [i ] = false;9: remainder section

10: end while

Process A

Kernel

Process B

turnflag[2]



Peterson’s solution1 This implementation preserves

1 Mutual exclusion2 Progress requirement3 Bounded-waiting requirement

2 Software-based solutions are notguaranteed to work on moderncomputer architectures

Modern CPUs reorder memoryaccesses to improve executionefficiency

3 Any solution to solve the criticalsection problem requires a lock

Process A

Kernel

Process B

turnflag[2]


SynchronisationSynchronisation hardware

Synchronisation hardware

Since software-based solutions are not guaranteed to work onmodern computer architectures, locks are utilised

Race conditions are prevented as critical sections areprotected by locks

Example: lock

1: while true do2: acquire lock3: critical section4: release lock5: remainder section6: end while



Synchronisation hardware

Many modern computer systemsprovide special hardware instructions

to test and modify the content of awordto swap contents of two words asone uninterruptable unit

We can use these instructions to solvethe critical section problem



TestAndSet()

1: boolean TestAndSet(boolean target){2: boolean rv = target;3: target = true;4: return rv;5: }

Swap()

1: void Swap(boolean a, boolean b){2: boolean temp = a;3: a = b;4: b = temp;5: }



Mutual exclusion with TestAndSet()

1: while true do2: while TestAndSet(&lock) do3: ; // do nothing4: end while5: // critical section6: lock = false;7: // remainder section8: end while



Mutual exclusion with Swap()

1: while true do2: key = true;3: while key do4: Swap(&lock, &key);5: end while6: // critical section7: lock = false;8: // remainder section9: end while



These algorithms satisfy the mutual exclusion requirement

Bounded-waiting requirement is not fulfilled

To fulfill all requirements, we define the data structures

1: boolean waiting[n];2: boolean key;

Initialised to false

Process Pi can enter its critical section only if

waiting[i]==false

or key == false



All requirements met with TestAndSet() (1/2)

1: while true do2: waiting[i]=true;3: key = true;4: while (waiting[i] && key) do5: key = TestAndSet(&lock);6: end while7: waiting[i]=false;8: // critical section9: j = (i + 1) mod (n);

10: while ((j!=i)&& !waiting[j]) do11: j = (j + 1) mod (n);12: end while13: [...]// code segment continued on next slide14: end while



All requirements met with TestAndSet() (2/2)

1: while true do2: [...]// code segment continued from last slide3: if j==i then4: lock = false;5: else6: waiting[j]=false;7: // remainder section8: end if9: end while



Mutual exclusion is met since

Process Pi can enter its critical section only if

waiting[i]==false

or key == false

Value key can become false only if TestAndSet() isexecuted.

Only the first process to execute TestAndSet() will find key== false

All other processes must wait

waiting[i] can become false only if another process leavesits critical section

Only one waiting[i] is set to false



Progress requirement is met since

A process exiting the criticalsection either sets

waiting[j]==false

or key == false

Both allow a process that iswaiting to enter its criticalsection to proceed

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection



Bounded waiting requirement is metsince

When a process leaves itscritical section it scans the arraywaiting in cyclic manner

(i+1,i+2,. . . ,n-1,0,. . . ,i-1)

It designates the first process inthis ordering that is in the entrysection (waiting[j]==true) asthe next one to enter the criticalsection

Any process waiting to enter itscritical section will do so withinn-1 turns

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection

remaindersection

critical section

exitsection

entrysection



However, hardware-based solutions also have some problems:

Unfortunately, for hardware designers, implementing atomicTestAndSet() instructions on multiprocessors is not a trivialtask.

Also, hardware-based solutions can be complicated forapplication programmers to use.

Another synchronisation tool that overcomes these difficultiesare Semaphores


SynchronisationSemaphores

Semaphores

Semaphore

A semaphore S is an integer variable

Accessed only through two standardatomic operations:

down()

up()



down(S)

1: down(S) {2: while (S≤0) do3: ; // no-op4: end while5: S−−;6: }

up(S)

1: up(S) {2: S++;3: }



All modifications to the integer value of the semaphore in theup() and down() operations must be executed individually

When one process modifies the semaphore value, no otherprocess can simultaneously modify the same semaphore value

Also, the operations S≤0 and S−− must be executed withoutinterruption



Usage

Binary semaphore

Value in {0, 1}Mutex (enable Mutual exclusion)Can be utilised to solve the critical section problem

Counting semaphore

Integer valueCan be utilised to control access to a resource consisting ofseveral instances

.



Mutexes can be utilised to solve the criticalsection problem

Example

1: while true do2: down(mutex);3: // critical section4: up(mutex);5: // remainder section6: end while



Implementation

Busy waiting

A process in its critical sectionblocks another process that tries toenter its critical sectionThe blocked process continuouslyloops on the entry codeBusy waiting wastes CPU cycles thatcould be utilised by other processesproductively



Implementation

To overcome the problem of busy waiting, we can modify thedefinition of the up() and down() statements.

Processes that have to wait are added to a waiting queue ofthe semaphore

The CPU scheduler selects another process from this listwhen the semaphore is freed.

The semaphore is then defined as

1: typedef struct {2: int value;3: processes list;4: }



Implementation

Definition of the down() segment without busy waiting

1: down(semaphore S){2: S.value−−;3: if S.value < 0 then4: add this process to S.list;5: block();6: end if7: }

The block() operation suspends the process that invokes it

List of processes implemented by a link field in each PCB

Each semaphore contains an integer value and a pointer to alist of PCBs



Implementation

Definition of the up() segment without busy waiting

1: up(semaphore S){2: S.value++;3: if S.value ≤ 0 then4: remove a process P from S.list;5: wakeup(P);6: end if7: }

The wakeup(P) operation resumes the execution of a blockedprocess P



Implementation

Semaphores have to be executedatomically

No two processes are allowed toexecuted up() and down() on thesame semaphore simultaneously

This can e.g. be solved by utilisinginterrupts on the entrance of thedown() segment



Deadlocks and starvation

When two or more processes are waiting on a semaphore, thismay result in a deadlock

Starvation is an event that can occur when processes in awaiting queue are waiting according to a LIFO-queue

Definition

A set of processes is in a deadlock, when each process in the set iswaiting for an event that can be caused only by another process inthe set.

Definition

A process is said to be in starvation, when it is in a situation inwhich it waits indefinitely within a semaphore.



Priority inversion

Due to synchronisation, higher priority processes can beblocked by lower priority processes

Higher priority process that access data currently accessed bya lower-priority process that is protected by a lock have towait

Consider a sequence of three processes with increasingpriorities:

L < M < HH requires resource R that is currently accessed by process LM becomes then runable and preempts LThen, M virtually blocks H



Solutions to priority inversion

Only an issue on systems with more than two priorities

Otherwise typically solved by priority inheritance protocol

Processes that require resources that can also be accessed byhigher priority processes temporarily gain this higher priorityThe priority is reverted when the process frees the resource.

L M Hlow highpriority

preemption



Example

In 1997 the NASA Sojourner rover landed on Mars

After it began operating it experienced frequent computerresets that prevented its operation

Problem: Higher priority task had a maximum expectedexecution time; experienced priority inversion

1

1http://research.microsoft.com/mbj/Mars Pathfinder/Authoritative Account.htmlStephan Sigg Operating Systems 44/79

SynchronisationClassic synchronisation problems

Classic synchronisation problems

Example

Many concurrency control problems exist

Following examples used to test new synchronisation schemes

Here we utilise semaphores for synchronisation

?Stephan Sigg Operating Systems 46/79


The Bounded-Buffer problem

Example

Producer-consumer problem

Producer produces information

This information consumed by consumer

e.g. Compiler produces assembly code which isconsumed by assembler

Possible solution:

Circular buffer

Filled by producerRead by consumer



semaphore mutex = 1

semaphore empty = n

semaphore full = 0

Producer process

1: while true do2: // produce item in nextp3: down(empty);4: down(mutex);5: // add nextp to buffer6: up(mutex);7: up(full);8: end while

Consumer process

1: while true do2: down(full);3: down(mutex);4: // remove item from

buffer to nextc5: up(mutex);6: up(empty);7: // consume the item in

nextc8: end while



The Readers-Writers problem

When several processes read and write on shared data

While read processes do not have to be synchronised

A write to the shared data, however may result in chaos

?Stephan Sigg Operating Systems 49/79


A solution to the Readers-Writers problem

Initialise:

semaphore mutex = 1;

semaphore wrt = 1;

int readcount = 0;

Structure of a writer process

1: while true do2: down(wrt)3: // writing is performed4: up(wrt);5: end while

Structure of a reader process

1: down(mutex);2: readcount++;3: if readcount == 1 then4: down(wrt);5: end if6: up(mutex);7: // reading is performed8: down(mutex);9: readcount−−;

10: if readcount==0 then11: up(wrt);12: end if13: up(mutex)



The Dining-philosophers problemImportant/popular cs-problem

n philosophers think or dine

When hungry, eats with nearest 2chopsticks

When finished eating, puts chopsticsback onto the table

Philosopher can take chopsticks notfrom other philosophers



Solutions to the Dining-philosophers problem

At most n − 1 philosophers may sit atthe table

A philosopher may pick up thechopsticks only if both are available

Can be realised when chopsticks arepicked in the critical section

Odd philosophers pick their rightchopstick first while even philosopherspick their left chopstick first


SynchronisationMonitors

Monitors

Incorrect use of semaphores can result in timing errors

Programming errors that are hard to detect and sometimesnot reproducible:

Example

1: up(mutex);2: critical section3: down(mutex);

Example

1: down(mutex);2: critical section3: down(mutex);

Example

Processes mightomit down(mutex)or up(mutex)

The errors can be prevented by high-level synchronisationconstructs such as monitors



Usage

A monitor is an abstract data type

Private data is encapsulated with public methods

Operation on the data by means of these methods

Procedures defined within a monitor can only access thosevariables declared locally within the monitor

Local variables can only be accessed by local procedures

Monitor

Procedure A Procedure B Procedure C



Syntax of a monitor

1: monitor monitor name {2: // shared variable declarations3: procedure P1 ( . . . ) {. . . }4: procedure P2 ( . . . ) {. . . }5: . . .6: procedure Pn ( . . . ) {. . . }7: initialisation code ( . . . ) {. . . }8: }

Monitor




Usage

Monitor ensures that only one process is active simultaneouslywithin the monitor

Programmer does not care about synchronisation

Synchronisation implemented by monitor

Synchronisation by the definition of variables within themonitor

condition x;

x.down();

x.up();



Usage

Monitor


Initialisation code

Shared data



Monitor


Initialisation code

Shared data

X

y

cond: x|y

+

en

try

co

nd

itio

ns



Dining philosophers solution using monitors

We introduce the data structure

enum{THINKING, HUNGRY, EATING}state[n]Philosopher i can set the variable state[i]=EATING only ifneighbours are not eating:

state[(i + n − 1) mod (n) 6= EATING]state[(i + 1) mod (n) 6= EATING]

condition self[n]

.



monitor Dining Philosophers (1/3)

1: void pickup (int i){2: state[i]=HUNGRY;3: test(i);4: if state[i ] 6= EATING then5: self[i].down();6: end if7: }8: ...




1: ...2: void putdown(int i){3: state[i]=THINKING;4: test((i + n − 1) mod n);5: test((i + 1) mod n);6: }7: ...




1: ...2: void test(int i) {3: if (state[(i + n − 1) mod (n)]) 6= EATING&&state[i ] ==

HUNGRY &&(state[(i + 1) mod 5 6= EATING ) then4: state[i]=EATING;5: self[i].up();6: end if7: }8: initialisationCode(){9: for i = 0 to n − 1 do

10: state[i]=THINKING;11: end for



Philosopher i must respect the order

DiningPhilosophers.pickup(i);...eat...DiningPhilosophers.putdown(i);

This solutions ensures that nodeadlocks will occur


SynchronisationAtomic transactions

Sometimes it is required that operations are not interleavedby other operations

These operations are then viewed as one atomic action

Example

Bank transfer

Either both credit and debit occurOr neither occurs

Any other condition is not acceptable

Both operations shall be executed as one atomic operationthat is not interleaved by any other operation

Atomic operation either executed completely or not executed.

Partial execution is not possible



Transaction

A collection of instructions (or operations) that performs a singlelogical function is called a transaction

Major issue in processing transactions

Ensure atomicity despite the possibility of failures within thecomputer



A transaction can be seen as a sequence of read and writeoperations

Terminated by a

commit operation (success)abort operation (failure)

Aborted transaction may have modified data already

To ensure atomicity, the system must roll back the systemstate to the time before the transaction started



Log-based recovery

Record information describing all modifications made by atransaction

Commmon form: Write-ahead logging

System maintains a log to describe each single operation of atransaction:

Trans name Unique name of the transactionData name Unique name of the data item

Old value Old value of the data itemNew value New value of the data item



Log-based recovery

In order to ensure that no information is lost, the log iswritten in advance of the actual operation

Therefore, the performance of this approach is low

For each logical write, two physical writes are required

When the data are extremely important, this mechanism is,however, required

The system can handle any failure that does not result in theloss of the log



Checkpoints

When a system failure occurs the entire log is searched foroperations that need to be redone or undone

This search process is time consuming

The concept of Checkpoints colorblack improves on thisproblem

The system periodically performs checkpoints that require thefollowing sequence of actions:

1 Output all log records residing in volatile storage to stablestorage

2 Output all modified data residing in volatile storage to stablestorage

3 Output a log record (checkpoint) onto stable storage

Operations prior to checkpoints are considered successfullycompleted



Concurrent atomic transactions

When multiple atomic transactions are executedsimultaneously, the system must ensure their serialisability

Result of the interleaving operations must be identical toresult of serial operation.

We can ensure this by implementing a single mutex used byall transactions

This solution, however, is too restrictive



Concurrent atomic transactions – Serialisability

Transactions can be executedfollowing a

Serial schedule

Instructions belonging to onetransaction are executedconcurrently

Nonserial schedule

Instructions belonging to onetransaction are interleaved withinstructions from othertransactions

T0 T1read(A)

write(A)

read(B)

write(B)

read(A)

write(A)

read(B)

write(B)serial schedule



Concurrent atomic transactions – Serialisability

A nonserial schedule does notnecessarily imply an incorrectexecution

Conflicting operations

Two operations conflict if they accessthe same data item

And at least one of the operations is awrite

Two consecutive operations do notconflict if the order can be exchangedwithout altering the computed result

T0 T1read(A)

write(A)

read(A)

write(A)

read(B)

write(B)

read(B)

write(B)non-serial schedule



Concurrent atomic transactions – Locking protocol

Serialisability can be ensured by alocking protocol

Each data item is associated with alockA transaction must first acquire thelock on the data item before it canaccess it

T0 T1read(A)

write(A)

read(A)

write(A)

read(B)

write(B)

read(B)

write(B)non-serial schedule



Concurrent atomic transactions – Timestamp based protocols

Serialisability can be ensured by atimestamp based protocol

Serialisability is then ensured bydefining the order in whichtransactions are allowed to accessdata itemsThe most common method for this isto use a timestamp

Each transaction is associatedwith a fixed timestampIn advance of executionTimestamps define priority/orderin which transactions on a singledata item are executed

T0 T1read(B)

read(B)

write(B)

read(A)

read(A)

write(A)schedule possibleunder a timestampprotocol


SynchronisationQuestions, discussion, remarks

Questions?


LiteratureRecommended literature

A. Tanenbaum, Moderne Betriebssysteme, 2nd edition,Prentice Hall, 2009.

A. Tanenbaum, Modern operating systems, 3rd edition,Prentice Hall, 2008.

A. Silberschatz et al. Operating system concepts, Wiley, 2004.

W. Stallings, Operating systems, 6th edition, Prentice Hall,2008.


OutlineSynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions