operating systems - synchronisation€¦ · operating systems synchronisation stephan sigg...
TRANSCRIPT
-
Operating SystemsSynchronisation
Stephan Sigg
Distributed and Ubiquitous SystemsTechnische Universitä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
Stephan Sigg Operating Systems 2/79
-
OutlineSynchronisation
1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions
Stephan Sigg Operating Systems 3/79
-
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
Stephan Sigg Operating Systems 4/79
-
SynchronisationIntroduction
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}
Stephan Sigg Operating Systems 5/79
-
SynchronisationIntroduction
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
Stephan Sigg Operating Systems 6/79
-
OutlineSynchronisation
1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions
Stephan Sigg Operating Systems 7/79
-
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
Stephan Sigg Operating Systems 8/79
-
SynchronisationThe critical section problem
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
Stephan Sigg Operating Systems 9/79
-
SynchronisationThe critical section problem
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
Stephan Sigg Operating Systems 10/79
-
SynchronisationThe critical section problem
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
Stephan Sigg Operating Systems 11/79
-
SynchronisationThe critical section problem
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
Stephan Sigg Operating Systems 12/79
-
SynchronisationThe critical section problem
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
Stephan Sigg Operating Systems 13/79
-
SynchronisationThe critical section problem
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]
Stephan Sigg Operating Systems 14/79
-
SynchronisationThe critical section problem
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]
Stephan Sigg Operating Systems 15/79
-
SynchronisationThe critical section problem
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]
Stephan Sigg Operating Systems 16/79
-
OutlineSynchronisation
1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions
Stephan Sigg Operating Systems 17/79
-
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
Stephan Sigg Operating Systems 18/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 19/79
-
SynchronisationSynchronisation hardware
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: }
Stephan Sigg Operating Systems 20/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 21/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 22/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 23/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 24/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 25/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 26/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 27/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 28/79
-
SynchronisationSynchronisation hardware
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
Stephan Sigg Operating Systems 29/79
-
OutlineSynchronisation
1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions
Stephan Sigg Operating Systems 30/79
-
SynchronisationSemaphores
Semaphores
Semaphore
A semaphore S is an integer variable
Accessed only through two standardatomic operations:
down()
up()
Stephan Sigg Operating Systems 31/79
-
SynchronisationSemaphores
down(S)
1: down(S) {2: while (S≤0) do3: ; // no-op4: end while5: S−−;6: }
up(S)
1: up(S) {2: S++;3: }
Stephan Sigg Operating Systems 32/79
-
SynchronisationSemaphores
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
Stephan Sigg Operating Systems 33/79
-
SynchronisationSemaphores
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
.
Stephan Sigg Operating Systems 34/79
-
SynchronisationSemaphores
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
Stephan Sigg Operating Systems 35/79
-
SynchronisationSemaphores
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
Stephan Sigg Operating Systems 36/79
-
SynchronisationSemaphores
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: }
Stephan Sigg Operating Systems 37/79
-
SynchronisationSemaphores
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
Stephan Sigg Operating Systems 38/79
-
SynchronisationSemaphores
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
Stephan Sigg Operating Systems 39/79
-
SynchronisationSemaphores
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
Stephan Sigg Operating Systems 40/79
-
SynchronisationSemaphores
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.
Stephan Sigg Operating Systems 41/79
-
SynchronisationSemaphores
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
Stephan Sigg Operating Systems 42/79
-
SynchronisationSemaphores
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
Stephan Sigg Operating Systems 43/79
-
SynchronisationSemaphores
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
-
OutlineSynchronisation
1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions
Stephan Sigg Operating Systems 45/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
-
SynchronisationClassic synchronisation problems
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
Stephan Sigg Operating Systems 47/79
-
SynchronisationClassic synchronisation problems
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
Stephan Sigg Operating Systems 48/79
-
SynchronisationClassic synchronisation problems
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
-
SynchronisationClassic synchronisation problems
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)
Stephan Sigg Operating Systems 50/79
-
SynchronisationClassic synchronisation problems
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
Stephan Sigg Operating Systems 51/79
-
SynchronisationClassic synchronisation problems
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
Stephan Sigg Operating Systems 52/79
-
OutlineSynchronisation
1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions
Stephan Sigg Operating Systems 53/79
-
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
Stephan Sigg Operating Systems 54/79
-
SynchronisationMonitors
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
Stephan Sigg Operating Systems 55/79
-
SynchronisationMonitors
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
Procedure A Procedure B Procedure C
Stephan Sigg Operating Systems 56/79
-
SynchronisationMonitors
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();
Stephan Sigg Operating Systems 57/79
-
SynchronisationMonitors
Usage
Monitor
Procedure A Procedure B Procedure C
Initialisation code
Shared data
Stephan Sigg Operating Systems 58/79
-
SynchronisationMonitors
Monitor
Procedure A Procedure B Procedure C
Initialisation code
Shared data
X
y
cond: x|y
+
en
try
co
nd
itio
ns
Stephan Sigg Operating Systems 59/79
-
SynchronisationMonitors
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]
.
Stephan Sigg Operating Systems 60/79
-
SynchronisationMonitors
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: ...
Stephan Sigg Operating Systems 61/79
-
SynchronisationMonitors
monitor Dining Philosophers (1/3)
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: ...
Stephan Sigg Operating Systems 62/79
-
SynchronisationMonitors
monitor Dining Philosophers (3/3)
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
Stephan Sigg Operating Systems 63/79
-
SynchronisationMonitors
Philosopher i must respect the order
DiningPhilosophers.pickup(i);...eat...DiningPhilosophers.putdown(i);
This solutions ensures that nodeadlocks will occur
Stephan Sigg Operating Systems 64/79
-
OutlineSynchronisation
1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions
Stephan Sigg Operating Systems 65/79
-
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
Stephan Sigg Operating Systems 66/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 67/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 68/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 69/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 70/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 71/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 72/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 73/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 74/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 75/79
-
SynchronisationAtomic transactions
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
Stephan Sigg Operating Systems 76/79
-
SynchronisationQuestions, discussion, remarks
Questions?
Stephan Sigg Operating Systems 77/79
-
OutlineSynchronisation
1 SynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions
Stephan Sigg Operating Systems 78/79
-
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.
Stephan Sigg Operating Systems 79/79
OutlineSynchronisationThe critical section problemSynchronisation hardwareSemaphoresClassic synchronisation problemsMonitorsAtomic transactions