Concurrent Systems II - Bad Request - Trinity College Dublin

Concurrent Systems II 

(CS3D4/CS3BA29) 

Mike Brady 

ORI.G41, brady@cs.tcd.ie 

https://www.cs.tcd.ie/~brady/courses/ba/CS3BA29/3D4-3BA292009.pdf 

Trinity College Dublin 

© Mike Brady 2007–2009

POSIX 

• POSIX – Portable Operating System Interface 

◾for variants of Unix, including Linux 

◾IEEE 1003, ISO/IEC9945 

• Really, considered a standard set of facilities and APIs for Unix. 

◾1988 onwards 

◾Doesn’t have to be Unix – e.g. Cygwin for Windows give it partial 

POSIX compilance 

◾ref: http://en.wikipedia.org/wiki/POSIX 

2 



POSIX Threads 

• POSIX Threads aka ‘pthreads’ 

◾correspond to ‘Light Weight Processes’ (LWPs) in older literature. 

◾pthreads live within processes. 

◾processes have separate memory spaces from one another 

• thus, inter-process communication & scheduling may be expensive 

◾pthreads (within a process) share the same memory space 

• inter-thread communication & scheduling can be cheap 

3 



POSIX Threads (2) 

• Portable Threading Library across Unix OSes 

◾All POSIX-compliant Unixes implement pthreads 

• Linux, Mac OS X, Solaris, FreeBSD, OpenBSD, etc. 

• Also Windows: 

◾E.g. Open Source: pthreads-win32 

4 



Six Separate Threads 

Master Thread 

Join 

T1 

T2 

T4 

T5 

T6 

T3 

5 



Creating a pthread 

#include 

int pthread_create( 

pthread_t *thread, // the returned thread id 

const pthread_attr_t *attr, // starting attributes 

void *(*start_routine)(void*), // the function to run in the thread 

void *arg); // parameter 

6 



Where… 

• ‘thread’ is the ID of the thread 

• 

• 

‘attr’ is the input-only attributes (NULL for standard attributes) 

‘start_routine’ (can be any name) is the function that runs when 

the thread is started, and which must have the signature: 

void* start_routine (void* arg); 

• ‘arg’ is the parameter that is sent to the start routine. 

• returns a status code. ‘0’ is good, ‘-1’ is bad. 

7 



wait for a thread to exit 

int pthread_join(pthread_t thread, void **value_ptr); 

where 

‘thread’ is the id of the thread you wish to wait on 

‘value ptr’ is where the thread’s exit status will be placed on exit 

(NULL if you’re not interested.) 

•NB: a thread can be joined only to one other thread! 

8 



Hello World -- Creating Threads 

int main (int argc, const char * argv[]) { 

pthread_t threads[NUM_THREADS]; 

int rc,t; 

for (t=0;t

Hello World -- Waiting for Exit 

// wait for threads to exit 

for(t=0;t

Hello World -- Thread Function 

void *PrintHello(void *threadid) { 

printf("\n%d: Hello World!\n", threadid); 

pthread_exit(NULL); 

} 

11 



HelloWorld -- Complete 

#include 

#include 

#include 

#define NUM_THREADS 6 

void *PrintHello(void *threadid) { 

printf("\n%d: Hello World!\n", threadid); 

pthread_exit(NULL); 

} 

int main (int argc, const char * argv[]) { 

pthread_t threads[NUM_THREADS]; 

int rc,t; 

for (t=0;t

Wilde/Stoker/Ubuntu 

h-3.1$ cc -lpthread main.c -o main 

h-3.1$ ./main 

• Include the pthread library to allow it to compile and link 

• Automatically included in Mac OS X 

13 



What’s wrong deceptive about this? 

Master Thread 

Join 

T1 

T2 

T4 

T5 

T6 

T3 

14 



Interaction 

• No thread interaction shown. 

• 

Most of the issues to do with threads (really, with any kind of 

parallel processing) arise over unforeseen interaction sequences. 

◾For example, if two threads attempt to increment the same 

variable 

15 



Unsafe Interaction Example 

Thread 1 Thread 2 G 

L=G 

(4) 

L=L+10 

(14) 

– 4 

– 4 

G=L 

L=G 

(4) 

L++ 

(5) 

4 

14 

G=L 5 

G = Global Variable; L = Separate Local Variables 

16 



Interactions & Dependencies 

• Interactions occur because of dependencies. 

• 

Interactions can be made safe using a variety of techniques. 

◾E.g. semaphores, condition variables, etc. 

• We will look at them… 

• They tend to be expensive; sometimes very expensive. 

• 

• 

But, sometimes we can redesign the code to avoid dependencies. 

One of the biggest themes in this kind of programming is 

dependency minimisation. 

17 



We need to use our knowledge of… 

• Sequential imperative programming, in C/C++ on a single 

processor. 

• How programs could communicate. 

18 



…to do Parallel Programming 

• High performance parallel programming 

• 

• 

We will confine ourselves to shared-memory machines. 

We will use dual-core (maybe quad-core) machines for practice. 

19 



Why is it this difficult? 

• It’s not clear whether it really is more difficult to think about 

using multiple agents, e.g. multiple processors, to solve a 

problem: 

◾Maybe we are brainwashed into thinking about just one agent; 

◾Maybe it’s natural; 

◾Maybe it’s our notations and toolsets; 

◾Of course, maybe it really is trickier. 

20 



Hardware 

Main Memory 

Level 2 Cache 

Level 1 Cache 

CPU 

Single Processor 

21 



Hardware 

Memory 

Cache 

CPU 

Bus 

… … … 

Cache 

CPU 

Multiple Processor 

22 



Shared Memory Machine 

• Each processor has equal access to each main memory location 

– Uniform Memory Access (UMA). 

◾Opposite: Non-Uniform Memory Access (NUMA) 

• Each processor may have its own cache, or may share caches 

with others. 

◾May have problems with cache issues, e.g. consistency, line-sharing, 

etc. 

23 



Sequential Program 

• A Sequential Program has one site of program execution. At any 

time, there is only one site in the program where execution is 

under way. 

• The Context of a sequential program is the set of all variables, 

processor registers (including hidden ones that can affect the 

program), stack values and, of course, the code, assumed to be 

fixed, that are current for the single site of execution. 

• The combination of the context and the flow of program 

execution is often called [informally] a thread. 

24 



Concurrent Program 

• A Concurrent Program has more than one site of execution. That 

is, if you took a snapshot of a concurrent program, you could 

understand it by examining the state of execution in a number of 

different sites in the program. 

• Each site of execution has its own context—registers, stack 

values, etc. 

• Thus, a concurrent program has multiple threads of execution. 

25 



Parallel Program 

• A Parallel Program, like a concurrent program, has multiple 

threads of program execution. 

• The key difference between concurrent and parallel is 

◾In concurrent programs, only one execution agent is assumed to 

be active. Thus, while there are many execution sites, only one will 

be active at any time. 

◾In parallel programs, multiple execution agents are assumed to be 

active simultaneously, so many execution sites will be active at any 

time. 

26 



Communication 

• A parallel program consists of two or more separate threads of 

execution, that run independently except when they have to 

interact 

• To interact, they must communicate 

• 

Communication is typically implemented by 

◾ sharing memory 

• One thread writes data to memory; the other reads it 

◾passing messages 

• One thread sends a message; the other gets it 

27 



Dependency 

• Independent sections of code can run independently. 

• We can analyse code for dependencies. 

◾To preserve the meaning of the program; 

◾To transform the program to reduce dependencies and improve 

parallelism. 

28 



1 – Flow Dependence 

S1: write to location L 

S2: read from location L 

• Flow Dependence: S2 is flow dependent on S1 because S2 reads 

a location S1 writes to. 

◾It must be written to (S1) before it’s read from (S2) 

29 



2 – Antidependence 

S1: read from location L 


• Antidependence: S2 is antidependent on S1 because S2 writes to 

a location S1 reads from. 

◾It must be read from (S1) before it can be written to (S2) 

30 



3 – Output Dependence 



• Output dependence: S2 is output dependent on S1 because S2 

writes to a location S1 writes to. 

◾The value of L is affected by the order of S1 and S2. 

31 



Example 

S1: a = b + d; 

S2: c = a * 3; 

S3: a = b +c; 

S4: e = a / 2; 

32 



Dependence in Loops 

j k k 

i 

1 2 

j 

5 5 

7 

i 

21 24 

27 

3 4 

8 9 

10 

47 54 

71 

a b c 

33 



Sample Serial Solution 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 

for j = 1 to 2 

sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

34 



How can we transform it? 

• We can work out how to transform it by locating the 

dependencies in it. 

• Some dependencies are intrinsic to the solution, but 

• 

Some are artefacts of the way we are solving the problem; 

◾If we can identify them, perhaps we can modify or remove them. 

35 



Try three execution agents: 

with k = 1; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

with k = 2; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

with k = 3; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

36 



Issues: 

• The variable sum, as written, is common to all three programs. 

• Solution: 

◾Make sum private to each program to avoid this dependency. 

37 



Try Six Execution Agents 

with k = 1, i=1; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

with k = 2, i=1; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

with k = 3, i=1; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

with k = 1, i=2; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

with k = 2, i=2; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

with k = 3, i=2; 

for i = 1 to 2 { 

for k = 1 to 3 { 

sum = 0.0; 


sum = sum + a[1,j] * b[j,k]; 

c[i,k] = sum; 

} 

} 

38 



Summarising: 

• We could parallelise the original algorithm with some care: 

◾Private Variables to avoid unnecessary dependencies 

• Actually, we could break this ‘Embarrassingly Parallel’ problem 

into tiny separate pieces; maybe too small. (How will we know?) 

39 



Example: Numerical Integration 

f(x) 

X 

a 

b 

Numerically integrate from a to b 

40 



Example 

• Sample function: y = 0.1x3 -0.4x 2 +2 

(b − a)(f(a) + f(b)) 

2 

41 



Concurrent Systems II 

Practical 1 

Practical 1 

February 24, 2009 

This practical is worth 2% of your year-end result. Have your program ready one week 

from the date of the practical—i.e. have it ready for inspection on March 3 at 11 am. 

Have a printout also. 

• Write a complete threaded program in C (or non-OO C++) on a Linux machine— 

e.g. stoker.cs.tcd.ie—to compute the value π. You’ll need to find some way to 

do this with, for instance, a series or an integral so that you can use an embarrassingly 

parallel approach. 

• Find out how to measure elapsed time in the Linux environment and do some measurements. 

From the measurements, can you deduce how many processors/cores 

are in the machine? 

Here is what connecting to stoker looks like over an ssh link: 

42 



Synchronisation 

• We’ve looked at situations where the threads can operate 

independently -- the ‘write sets’ of the threads don’t intersect. 

• Where the write sets intersect, we must ensure that 

independent thread writes do not damage the data. 

43 


© Mike Brady 2007

Shared Variable S: Thread 1 before Thread 2 

A Thread 1 S Thread 2 

Time 

25 

25 A=S 25 

26 A++ 25 B=S 25 

26 S=A 26 B*=10 250 

26 250 S=B 250 

26 250 250 

Thread 2 accesses S after Thread 1 but before Thread 1 has finished updating S 

44 


© Mike Brady 2007

Shared Variable S: Thread 1 after Thread 2 

A Thread 1 S Thread 2 B 

Time 

25 

25 25 B=S 25 

25 A=S 25 B*=10 250 

26 A++ 250 S=B 250 

26 S=A 26 250 

26 26 250 

Thread 1 accesses S after Thread 2 but before Thread 2 has finished modifying S 

45 


© Mike Brady 2007

Synchronisation 

• Problem: Access to shared resources can be dangerous. 

◾These are so-called ‘critical’ accesses. 

• Solution. Critical accesses should be made exclusive. Thus, all 

critical accesses to a resource are mutually exclusive. 

• In the example, both threads should have asked for exclusive 

access before making their updates. 

◾Depending on timing, one or the other would get exclusive access 

first. The other would have to wait to get any kind of access. 

46 


© Mike Brady 2007

Mutual Exclusion in pthreads. 

• Mutual Exclusion is accomplished using ‘mutex’ variables. 

• 

Mutex variables are used to protect access to a resource. 

47 


© Mike Brady 2007

Accessing a protected resource 

• To access a mutex-protected resource, an agent must acquire a 

lock on the mutex variable. 

◾If the mutex variable is unlocked, it is immediately locked and the 

agent has acquired it. When finished, the agent must unlock it. 

◾If the mutex variable is already locked, the agent has failed to 

acquire the lock -- the protected resource is in exclusive use by 

someone else. 

• The agent is usually blocked until lock is acquired. 

• A non-blocking version of lock acquisition is available. 

48 


© Mike Brady 2007

Shared Variable S Protected by Mutex M 

A Thread 1 S Thread 2 B M 

Lock(M) 25 locked 

25 A=S 25 Lock(M) locked 

26 A++ 25 

locked 

26 S=A 26 

[thread 

blocked] 

locked 

26 Unlock(M) 26 

locked 

26 26 B=S 26 locked 

26 B*=10 260 locked 

260 S=B 260 locked 

260 Unlock(M) locked 

260 unlocked 

Time 

49 


© Mike Brady 2007

Create pthread mutex variable 

• Static: 

◾pthread_mutex_t m = PTHREAD_MUTEX_INITIALISER; 

• Initially unlocked 

• Dynamic 

◾pthread_mutex_init(,attributes) 

50 


© Mike Brady 2007

Lock and Unlock Mutex 

• pthread_mutex_lock(); 

◾acquire lock or block while waiting 

• pthread_mutex_tryunlock(); 

◾non-blocking; check returned code 

• pthread_mutex_unlock(); 

51 


© Mike Brady 2007

Example (1 of 2) – Thread 

main.c 23/02/2009 10 

#include 

#include 

#include 

#include 

#define checkResults(string, val) { \ 

if (val) { \ 

printf("Failed with %d at %s", val, string); \ 

exit(1); \ 

} \ 

} 

// From http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzahw/rzahwe18rx.htm 

// Fixed to avoid calls to non-standard pthread_getthreadid_np() 

#define NUMTHREADS 3 

pthread_mutex_t 

mutex = PTHREAD_MUTEX_INITIALIZER; 

int 

sharedData=0; 

int 

sharedData2=0; 

void *theThread(void *threadid) 

{ 

int rc; 

printf("Thread %.8x: Entered\n", (int)threadid); 

rc = pthread_mutex_lock(&mutex); 

checkResults("pthread_mutex_lock()\n", rc); 

/********** Critical Section *******************/ 

printf("Thread %.8x: Start critical section, holding lock\n",(int)threadid); 

/* Access to shared data goes here */ 

++sharedData; --sharedData2; 

printf("Thread %.8x: End critical section, release lock\n",(int)threadid); 


} 

rc = pthread_mutex_unlock(&mutex); 

checkResults("pthread_mutex_unlock()\n", rc); 

return NULL; 

52 

int main(int argc, char **argv) 

{ 

pthread_t 

thread[NUMTHREADS]; 

int 

rc=0; 

int i; 


© Mike Brady 2007 

printf("Enter Testcase - %s\n", argv[0]);

} 


printf("Thread %.8x: Start critical section, holding lock\n",(int)threadid); 

/* Access to shared data goes here */ 

++sharedData; --sharedData2; 

printf("Thread %.8x: End critical section, release lock\n",(int)threadid); 


Example (2 of 2) – Main 

rc = pthread_mutex_unlock(&mutex); 

checkResults("pthread_mutex_unlock()\n", rc); 

return NULL; 

int main(int argc, char **argv) 

{ 

pthread_t 

thread[NUMTHREADS]; 

int 

rc=0; 

int i; 

printf("Enter Testcase - %s\n", argv[0]); 

printf("Hold Mutex to prevent access to shared data\n"); 

rc = pthread_mutex_lock(&mutex); 

checkResults("pthread_mutex_lock()\n", rc); 

printf("Create/start threads\n"); 

for (i=0; i

Problems 

• Voluntary 

◾Mutexes ‘protect’ code. 

◾Other programmers don’t have to use them to get access to the 

variables the code accesses. 

• Unfair 

• This is part of the tradeoff. Use processes rather than threads if you 

want better protection. 

◾If multiple threads are blocked on a mutex, the order in which 

they waken up is not guaranteed to be any particular order. 

54 


© Mike Brady 2007

Problem Tutorial 

• The transpose of a matrix M is a matrix T, where: 

T[i,j] = M[j,i] for all i, j. 

• Write a program to transpose a matrix. 

• How would you parallelise it? 

• What problems/issues do you foresee? 

55 



Problems 

• Voluntary 

◾Mutexes ‘protect’ code. 

◾Other programmers don’t have to use them to get access to the 

variables the code accesses. 

• Unfair 

• This is part of the tradeoff. Use processes rather than threads if you 

want better protection. 

◾If multiple threads are blocked on a mutex, the order in which 

they waken up is not guaranteed to be any particular order. 

56 


© Mike Brady 2007

Producers and Consumers 

• Essentially a pipeline of separate sequential programs. 

◾E.g. concatenation of unix commands. 

• Programs communicate via buffers. 

◾Implemented in different ways, but, e.g. 

• Shared memory, flags, semaphores, etc. 

• Message passing over a network 

• 

Flow of data is essentially one-way. 

• Example… 

57 



Condition Variables 

• A generalised synchronisation construct. 

• 

Allows you to acquire mutex lock when a condition relying on a 

shared variable is true and to sleep otherwise. 

• The ‘conditon variable’ is used to manage the mutex lock and the 

signalling. 

• Slightly tricky. 

58 


© Mike Brady 2007

Condition Variables (2) 

• Dramatis Personae: 

◾A mutex variable M, 

◾A shared resource R to be guarded by M, 

◾A condition variable V, 

◾A condition C, 

◾A thread U that wishes to use R, protected by M, on condition 

that C is true, 

◾A thread S that will modify V. 

59 


© Mike Brady 2007

From Thread U’s POV (1) 

• Acquire Mutex M 

◾This controls access to R, 

◾but also must control access to any shared variables that C 

depends on. 

• If C is true, continue – the mutex is available unfettered, 

◾i.e. if C is true, the mutex can be used as normal. 

• if C is false… 

60 


© Mike Brady 2007


• If C is false, wait for condition variable V to be signalled. 

• This is tricky, as access to V is controlled by M. 

◾So, Mutex M is unlocked, 

◾Thread sleeps, to be woken when V is signalled, 

◾Then, M is re-acquired. 

• No guarantee you’ll get it right away–maybe another thread will. 

• So now, if V has been signalled… 

61 


© Mike Brady 2007


• Since V has been signalled, there is a chance that the condition C 

is now true. 

• Re-evaluate C: 

◾If true, then the mutex is available for you to use, 

◾If false, back to previous page. 

• Our ‘if’ needs to be replaced by a ‘while’… 

62 


© Mike Brady 2007



• While !C 

◾Unlock M 

◾Wait for V to be changed 

◾Lock M 

• Continue 

• Unlock M (finished) 

pthread_lock(&m) 

while (!C) 

pthread_cond_wait(&v,&m) 

or 

pthread_cond_timedwait(& 

v,&m,) 

continue 

pthread_unlock(&m) 

63 


© Mike Brady 2007

Thread S (1) 

• Thread U is the ‘user’ of the condition variable V. 

• 

If the condition is not true, U unlocks V’s mutex M and sleeps, 

waiting for prince charming some other thread S to signal V and 

thereby waking U to check the condition again. 

64 


© Mike Brady 2007

Thread S (2) 


• Do something 

• Unlock Mutex M 

• 

Signal the condition variable 

◾This will awaken a thread 

that is waiting on the 

condition variable. 

pthread_lock(&m) 

Do something 

pthread_unlock(&m) 

pthread_cond_signal(&v) 

or 

pthread_cond_broadcast( 

&v) 

65 


© Mike Brady 2007

Semaphores 

• Semaphore = sema [signal] + phoros [bearer] (from Greek). 

• 

Historically, semaphores were used for long-distance optical 

signalling, e.g. lanterns, flags, coloured arms, etc. 

◾ E.g. Semaphores (“the Chappe system”) were used in France from 

late 1700s to mid 1800s for military and governmental use. 

66 


© Mike Brady 2007

Semaphores 

• Computer Semaphores [specifically “counting semaphores”] 

invented by Edsger W. Dijkstra, named after signalling 

semaphores. 

• Can be thought of as a special case of a condition variable, a nonnegative 

counter value. 

• Producer and Consumer Threads 

• 

Can be implemented as a special case of Condition Variables 

67 


© Mike Brady 2007

Semaphore Producer 

• Acquire Mutex. 

• 

• 

• 

• Release Mutex 

 

Increment Semaphore Count 

Signal Condition Variable 

68 


© Mike Brady 2007

Semaphore Consumer 

◾Acquire Mutex 

◾While semaphore count = 0, 

• release mutex 

• sleep on Condition Variable 

• reacquire mutex 

◾Decrement semaphore count. 

◾ 

◾Release mutex 

69 


© Mike Brady 2007

Semaphores (2) 

• A semaphores package is also available as part of the POSIX 

Realtime Extensions. 

◾Small detail: these are ‘async safe’ in Unix – they can be used inside 

Unix signal handlers. 

70 


© Mike Brady 2007

Semaphores (3) 

• Useful for countable resources, e.g. buffers. 

◾Semaphore variable = resource count. 

• Can be used to prevent underflow and to limit count (i.e. 

prevent overflow). 

71 


© Mike Brady 2007

Clients and Servers 

• Somewhat similar to producer-consumer, but: 

◾Two-way flow of information between client and server, e.g. data 

supplied and result returned. 

◾Server may have many clients. 

• Widely used paradigm on distributed systems. 

72 



Sample Solution for ∏ 

• Calculate π using the formula 

below: 

2.5 

∫ 1 

0 

4 

1+x 2 

0 2.5 

73 



Amdahl’s Law 

• If a portion P of a job can be speeded up by a factor of S, 

then the speedup is given as: 

Speedup = 

• From this, you can calculate the efficiency of the parallelisation. 

1 

(1 − P )+ P S 

E = Speedup 

N 

74 



unsigned long long clock_cycles() 

{ 

unsigned long long int x; 

__asm__ volatile (".byte 0x0f, 0x31" : "=A" (x)); 

return x; 

Problem Tutorial 

} 

#elif __x86_64__ 

unsigned long long clock_cycles(void) 

{ 

unsigned hi, lo; 

__asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi)); 

return ( (unsigned long long)lo)|( ((unsigned long long)hi)

Good Practice… 

http://www.xkcd.com/292/ 

76 



The Challenge of Concurrency 

• Conventional testing and debugging is not generally useful. 

◾We assume that the sequential parts of concurrent programs are 

correctly developed. 

• Beyond normal sequential-type bugs, there is a whole range of 

problems caused by errors in communication and 

synchronisation. They can not easily be reproduced and 

corrected. 

• So, we are going to use notions, algorithms and formalisms to 

help us design concurrent programs that are correct by design. 

77 



Sequential Process 

• A sequential process is the execution of a sequence of atomic 

statements. 

◾E.g. Process P could consist of the execution of P1,P2,P3,…. 

◾Process Q could be Q1,Q2,Q3,…. 

• We think of each sequential process having its own separate PC 

and being a distinct entity. 

78 



Concurrent Execution 

• A concurrent system is modelled as a collection of sequential 

processes, where the atomic statements of the sequential 

processes can be arbitrarily interleaved, but respecting the 

sequentiality of the atomic statements within their sequential 

processes. 

• E.g. say P is P 1,P2 and Q is Q1,Q2. 

79 



Scenarios for P and Q. 

p1→q1→p2→q2 

p1→q1→q2→p2 

p1→p2→q1→q2 

q1→p1→q2→p2 

q1→p1→p2→q2 

q1→q2→p1→p2 

80 



Notation 

Trivial Concurrent Program (Title) 

integer n ←0 (Globals) 

p (Process Name) 

q 

integer k1 ← 1 (Locals) integer k2 ← 2 

p1: n ← k1 (Atomic Statements) p2: n ← k2 

81 



Sample Sequential Program 

p1: n ← k1 

p2: n ← k2 

integer k1 ← 1 

integer k2 ← 2 

Trivial Sequential Program 

integer n ←0 

p1: n ← k1 

k1 = 1, k2 = 2 

n = 0 

P2: n ← k2 

k1 = 1, k2 = 2 

n = 1 

(end) 

k1 = 1, k2 = 2 

n = 2 

82 



Trivial Concurrent Program 

p1: n ← k1 

q1: n ← k2 

k1 = 1, k2 = 2 

n = 0 

(end) 

q1: n ← k2 

k1 = 1, k2 = 2 

n = 1 

p1: n ← k1 

(end) 

k1 = 1, k2 = 2 

n = 2 

(end) 

(end) 

k1 = 1, k2 = 2 

n = 2 

(end) 

(end) 

k1 = 1, k2 = 2 

n = 1 

p1, q1 q1, p1 

83 



State Diagrams and Scenarios 

• We could describe all possible ways a program can execute with 

a state diagram. 

◾There is a transition between s1 and s2 (“s1:s2”) if executing a 

statement in s1 changes the state to s2. 

◾A state diagram is generated inductively from the starting state. 

• If ∃ s 1 and a transition s1:s2, then ∃ s2 and a directed arc from s1:s2 

• Two states are identical if they have the same variable values and 

the same directed arcs leaving them. 

• A scenario is one path through the state diagram. 

84 



Example — Jumping Frogs 

• A frog can move to an adjacent stone if it’s vacant. 

• 

A frog can hop over an adjacent stone to the next one if that 

one is vacant. 

• No other moves are possible. 

85 



Can we interchange the positions of the frogs? 

to 

86 



If the frogs can only move “forwards”, can we: 

to 

87 



Proof 

• We can prove interesting properties by trying to construct a 

state diagram describing 

◾each possible state of the system and 

◾each possible move from one state to another 

• We might use a state diagram to show that 

◾A property always holds 

◾A property never holds in any reachable state 

◾A property sometimes holds 

◾A property always holds eventually 

88 



State Diagrams for Processes 

• A state is defined by a tuple of 

◾for each process, the label of the statement available for 

execution. 

◾for each variable, its value. 

• Q: What is the maximum number of possible states in such a 

state diagram? 

89 



Course Link 

https://www.cs.tcd.ie/~brady/courses/ba/CS3BA29/3D4-3BA292009.pdf 

90 



Book Reference 

Principles of concurrent and distributed programming 

By M. Ben-Ari 

Edition: 2 

Published by Addison-Wesley, 2006 

Original from the University of Michigan 

Digitized Nov 16, 2007 

ISBN 032131283X, 9780321312839 

361 pages 

$125 at Amazon! 

91 



Correctness, fairness 

• We can use state diagram descriptions of concurrent 

computations to explore whether a concurrent progam is correct 

according to some criterion, or whether it is fair. 

92 



Correctness 

• (Correctness in Sequential Programs) 

◾Partial Correctness: The answer is correct if the program halts 

◾Total Correctness: The program does halt and the answer is 

correct. 

• Correctness in Concurrent Programs 

◾Safety Property: a property must be always true 

◾Liveness Property: a property must be eventually true 

93 



Fairness 

• Recall a concurrent program is modelled as the interleaving of 

statements in any possible way in a number of sequential 

programs. 

◾If a statement is ready for execution, then if it is guaranteed that it 

will eventually be executed (i.e. it will appear in a scenario), the 

system is said to be weakly fair. 

• Another way of thinking about this is that in a weakly fair 

system, the arbitrary interleaving of statements does not include 

scenarios in which available and ready statements will never be 

executed. 

• Sometimes we assume weak fairness for something to work. 

94 



Using State machines 

• We can describe concurrent programs using states and state 

transitions. 

• We can construct a state transition diagram (a “model”) which 

captures every possible scenario a concurrent program is 

capable of executing. 

• By reasoning with the model (“model checking”), we can prove 

whether or not a particular property holds for a concurrent 

program. 

• Much more powerful idea than merely testing a concurrent 

program. 

95 



The Critical Section Problem 

• This is to model a situation in which two or more endless processes 

have critical sections in which it is certain that only one process is 

executing, i.e: 

◾Statements from the critical regions of two or more process must not 

be interleaved. 

• We also need to be certain that processes are safe from one another 

in other ways: 

◾No deadlock: if some processes are trying to execute their critical 

sections, one will succeed, 

◾No starvation: if any process tries to execute its critical region, it will 

succeed eventually. 

96 



The Critical Section Problem (2) 

• We must develop some kind of a synchronization mechanism. 

◾Before the critical region, a sequence of setup statements called a 

preprotocol. 

◾After the critical region, a sequence of teardown statements called 

a postprotocol. 

• Our task is to develop pre- and postprotocols to ensure mutual 

exclusion from critical region execution, i.e. 

◾We must ensure that statements from the critical regions of 

processes are not interleaved. 

97 



Critical Section Processes Model 

p 

local variables 

loop forever 

non-critical section 

preprotocol 

critical section 

postprotocol 

Critical Section Problem 

global variables 

q 

local variables 

loop forever 

non-critical section 

preprotocol 

critical section 

postprotocol 

98 



Observations & Implications 

• Remember, we are using these ideas to model real programs. 

• 

We assume the protocols and the sections are independent of 

one another, not sharing variables, etc. 

• Critical sections must progress. It must be that the critical 

sections always complete their run-throughs, i.e. if a critical 

section is entered, we must be certain that it will exit. (Why?) 

• Non-critical sections should not be required to progress. (Why?) 

99 



Critical Section – First Try 


integer turn ← 1 

loop forever 

p 

loop forever 

q 

p1: non-critical section q1: non-critical section 

p2: await turn = 1 q2: await turn = 2 

p3: critical section q3: critical section 

p4: turn ← 2 q4: turn ← 1 

Total number of states possible: 4*4*2 = 32 

100 



Simplify 



loop forever 

p 

loop forever 

q 

p1: // non-critical section q1: // non-critical section 


p3: // critical section q3: // critical section 

p4: turn ← 2 q4: turn ← 1 

Sections and Protocols are independent of one another, by definition. 

If we comment out p3 (or q3), it’s as if we went straight to p4 (resp. q4). 

So, we can eliminate p3 (q3). Similarly with p1 (q1). 

101 



Simplify 



loop forever 

r 

loop forever 

s 

r1: NCS await turn = 1 s1: NCS await turn = 2 

r2: turn ← 2 s2: turn ← 1 

Total number of states possible: 2*2*2 = 8 

102 



State Transitions 

r1,s1,1 

r1: await turn = 1, 

s1: await turn = 2, 

turn = 1 

r1,s1,2 



turn = 2 

r2,s1,1 

r2,s1,1 

r2: turn ← 2, 


turn = 1 

r1,s2,2 


s2: turn ← 1, 

turn = 2 

r2,s1,2 

r2,s2,2 

r2,s2,1 

103 



Mutual Exclusion in Critical Sections? 

• Are the critical sections mutually exclusive? 

◾Yep: cannot be reached? ✔ 

104 



Deadlock Free? 

• Deadlock Free: If some processes are trying to enter their critical 

sections, it is certain that at least one will eventually succeed. 

• Proofs: 

◾In , process r will progress to r2. 

◾In a transition is guaranteed* to . 

◾In , process s will progress to s2. 

◾In , a transition is guaranteed* to . 

• Thus, guaranteed deadlock-free. 

*How does this guarantee work? 

105 



Starvation Free? 

• Starvation Free: If any process is trying to enter its critical sections, it is 

certain that it will eventually succeed. 

• Proofs: 

◾In , both processes are in their combined non-critical and 

preprotocol sections. 

◾Say s is ready to enter its critical region: it can’t because turn = 1, 

and only r can set it to 2. 

• But r is in its non-critical region, where progress is not guaranteed. 

◾We can’t be certain turn will ever change to 2. 

◾Thus, we can’t guarantee starvation free operation. ✖ 

106 



Scorecard 

Mutual Exclusion 

Deadlock Free 

Starvation Free 

✔ 

✔ 

✖ 

Basically, if one process dies in a non critical section, the other processes 

will be starved of access to their critical regions. Not good. 

Must Do Better: How about giving each process its own equivalent of a 

turn variable? -- a “want” variable? 

107 



Second Attempt 

• Two processes, p and q, each with their own ‘want’ variables 

wantp and wantq. 

• If a process wants to enter its critical section, it ensures the 

other process’ want variable is false and then asserts its own 

while its entering, is in, and is leaving its critical region. 

108 



Attempt #2 

Critical Section Problem Attempt #2 

boolean wantp ← false, wantq ← false 

loop forever 

p 

loop forever 

q 


p2: await wantq = false q2: await wantp = false 

p3: wantp ← true q3: wantq ← true 


p5: wantp ← false q5: wantq ← false 

Do you have an intuition about what might happen? 

109 



Attempt #2 Shortened 

loop forever 



p 

loop forever 




q 

Process p Process q wantp wantq 

p1: await wantq = false q1: await wantp = false FALSE FALSE 

p2: wantp ← true q1: await wantp = false FALSE FALSE 

p2: wantp ← true q2: wantq ← true FALSE FALSE 

p3: wantp ← false q2: wantq ← true TRUE FALSE 

p3: wantp ← false q3: wantq ← false TRUE TRUE 

110 



Attempt #2 Fails… 

• Attempt 2 fails because we can construct a scenario (a path 

through a state transition diagram) which shows that a state with 

p3 and q3 free to execute can be reached. These contain the 

critical regions of their processes. 

◾Thus: mutual exclusion is not guaranteed. 

111 



Attempt #3 

• Attempt #2 fails because of the ‘gap’ between finding out the 

other process is not attempting to get into its critical region and 

entering the critical region. 

◾(The other process could enter its critical region in the gap.) 

• So, attempt #3 works by claiming to enter the critical region 

before checking it’s okay by everyone else. 

◾i.e. Attempt #3 does assert wait before awaiting wait 

◾c.f. Attempt #2 does await wait before assert wait 

112 



Attempt #3 



loop forever 

p 

loop forever 

q 







113 



Attempt #3 Shortened 

loop forever 



p 

loop forever 




q 


p1: non critical section q1: non critical section FALSE FALSE 

p2: wantp ← true q1: non critical section FALSE FALSE 

p2: wantp ← true q2: wantq ← true FALSE FALSE 

p3: await wantq = false q2: wantq ← true TRUE FALSE 

p3: await wantq = false q3: await wantp = false TRUE TRUE 

114 




• Attempt 3 fails because we can construct a scenario which 

shows that a state with deadlock (actually this is livelock) can be 

reached. 

◾Thus: freedom from deadlock is not guaranteed. 

115 



Attempt #4 

• Attempt #3 fails because each process insisted on entering its 

critical region (by asserting its wait variable). 

◾Having insisted on entering, they could not proceed because they 

were waiting for all others to not be in their critical regions. 

• So, attempt #4 works by our process claiming to enter the 

critical region before checking it’s okay by everyone else. 

◾Then, if another process is in its critical region, our process 

relinquishes and reasserts its insistence on entering its critical 

region 

• i.e. Attempt #4 negates and then reasserts its wait variable. 

116 



Attempt #4 

loop forever 



p 

loop forever 



p3: while wantq q3: while wantp 





q 


117 



Fragment of a scenario… 


p3: while wantq q3: while wantp TRUE TRUE 

p3: while wantq q4: wantq ← false TRUE TRUE 

p4: wantp ← false q4: wantq ← false TRUE TRUE 

p4: wantp ← false q5: wantq ←true TRUE FALSE 

p5: wantp ← true q5: wantq ←true FALSE FALSE 

p5: wantp ← true q3: while wantp TRUE FALSE 

p3: while wantq q3: while wantp TRUE TRUE 

… 

Here is the possibility of an endless loop. 

118 




• Attempt 3 fails because we can construct a scenario which 

shows that a state with starvation can occur. 

◾Thus: freedom from starvation is not guaranteed. 

119 



Attempt #5 – Dekker’s Algorithm 

• Uses turn variable (Attempt #1) 

• 

Uses want and relinquishing insistence to critical region 

(Attempt #4) 

120 



Attempt #5, derived from #4 


boolean wantp ← false, wantq ← false, turn ← 1 

p 

q 

loop forever 

loop forever 




if turn = 2 if turn = 1 


await turn = 1 await turn = 2 



turn ← 2 turn ← 1 


121 



Dekker’s Algorithm 


boolean wantp ← false, wantq ← false, turn ← 1 

loop forever 

p 

loop forever 




p4: if turn = 2 q4 if turn = 1 





p9: turn ← 2 q9: turn ← 1 

p10 wantp ← false q10 wantq ← false 

q 

122 



Verification of concurrent programs 

• Manual construction and inspection of state diagrams 

– Only suitable for the most trivial programs with few states 

1 

• Automated construction and inspection of state diagrams 

– The task of constructing the state diagram and using it to check the correctness 

of the concurrent program can be automated using a model checker 

– The power of model checkers lies in their ability to handle very large numbers 

of states 

– We still need a way to specify models and logical correctness properties 

• Formal specification and verification using temporal logic 

3BA29/3D4 Concurrent Systems and Operating Systems 

http://www.cs.tcd.ie/Stephen.Childs childss@cs.tcd.ie

A quick overview of some mathematical logic 

• M. Ben-Ari, “Principles of Concurrent and Distributed 

Programming”, 2 nd edition, Chapter 4 and Appendix B 

2 

• Propositional calculus 

– atomic propositions {p,q,r,…} 

– unary operator ¬ (not) 

– binary operator ∨ (or) 

– binary operator ∧ (and) 

– binary operator → (implication) 

– binary operator ↔ (equivalence) 

• Semantics 

– An assignment function v maps propositions to {T,F} (true, false) 

– Once we have mapped propositions to truth values, we can interpret formulas 

according to the following rules 

– e.g. p is TRUE, q is FALSE so p ∨ q is TRUE but p ∧ q is FALSE 

– So the truth value is an interpretation, the interpretation function also given as v. 




3 

A v(A 1 ) v(A 2 ) v(A) 

¬ A 1 T F 

¬ A 1 F T 

A 1 ∨ A 2 F F F 

A 1 ∨ A 2 

otherwise 

T 

A 1 ∧ A 2 T T T 

A 1 ∧ A 2 

otherwise 

F 

A 1 → A 2 T F F 

A 1 → A 2 

otherwise 

T 

A 1 ↔ A 2 v(A 1 ) = v(A 2 ) 

A 1 ↔ A 2 v(A 1 ) ≠ v(A 2 ) 

T 

F 




• Material implication paradox 

4 

v(A 1 ) v(A 2 ) v(A 1 → A 2 ) 

F F T 

F T T 

T F F 

T T T 

• Consider: superman is real implies fish can swim 

– superman is real is FALSE 

– fish can swim is TRUE 

– so, by the rules of material implication, our statement is TRUE 

– this may seem counterintuitive 




• However, consider: “If it is sunny then I will be at the 

beach” 

5 

– Think of the statement as a guarantee 

– When is the guarantee broken? 

v(A 1 ) 

it is sunny 

v(A 2 ) 

I will be at the 

beach 

v(A 1 → A 2 ) 

F F T 

F T T 

T F F 

T T T 




• Proof by induction 

6 

• For natural numbers 

– First prove for n=1 

– Then assume for n 

– Then prove for n+1 

– e.g. prove F(n): the sum of the first n positive integers is n(n+1)/2 

• For states 

– First prove for initial state (base case) 

– Then assume A true in all states up to current state 

– Then prove it’s true in next state (may be more than one) 



Proving correctness by induction 

• We can prove correctness using induction 

– E.g. Prove that the critical section solution with “Critical Section Problem 

Attempt #3” guarantees mutual exclusion 

– formally, prove that ¬ (p4 ∧ q4) is invariant 

– an invariant must remain unchanged in every state of any execution 

– In our proof, we only need to consider statements that can change the value 

(truth) of one of our atomic propositions 

– By the properties of material implication, if a formula is assumed true by 

inductive hypothesis, it can only be falsified in two ways (see next slide) 

7 



loop forever 

p1: > 

p2: wantp ← true 

p3: await wantq = false 

p4: > 

p5: wantp ← false 

p 

loop forever 

q1: > 

q2: wantq ← true 

q3: await wantp = false 

q4 > 

q5: wantq ← false 

q 



Proving correctness by induction 

• The only two ways to falsify a true implication (p→q): 

– Take the case v(p) = v(q) = True 

– “Suddenly” v(q) becomes False, v(p) still True: p → q is now False 

8 

– Take the case v(p) = v(q) = F 

– “Suddenly” v(p) becomes True, v(q) remains False: p → q is now False 

v(p) v(q) v(p → q) 

F F T 

F T T 

T F F 

T T T 



A quick overview of some temporal logic 

• We have been assigning the value TRUE or FALSE to 

propositions to allow us to interpret formulas, for example 

… 

– A 1 → A 2 when A 1 is TRUE and is A 2 FALSE 

– If it is sunny then I will be at the beach, when “it is sunny” is TRUE and “I will be 

at the beach” is TRUE 

– p3..5 → wantp when p3..5 is FALSE and wantp is FALSE 

• This is insufficient to allow us to reason about concepts 

such as “eventually” or “always”, for example … 

– p3 → eventually wantp will be FALSE 

• Extend propositional calculus with temporal operators 

– (propositional) linear temporal logic (LTL) 

– M. Ben-Ari, “Principles of Concurrent and Distributed Programming”, 2 nd edition, 

section 4.3 

9 




• Computation 

– an infinite sequence of states {s 0 , s 1 , …} 

10 

• □, always 

– a formula □ A is true in a state s i if and only if the formula A is true in all states 

s j , j ≥ i, of the computation 

– recall safety and liveness 

– □ A is a safety property (e.g. □ x ≥ 0) 

• ◊, eventually 

– a formula ◊ A is true in state s i if and only if the formula A is true in some state 

s j , j ≥ i, of the computation 

– ◊ A is a liveness property (e.g. ◊ y, where y is a boolean variable) 




• Temporal operator duality 

– Remember deMorgan’s laws? 

– ¬ (A ∧ B) ↔ (¬ A ∨ ¬ B) 

– ¬ (A ∨ B) ↔ (¬ A ∧ ¬ B) 

11 

– Similarly 

– ¬ □ A ↔ ◊ ¬ A 

– ¬ ◊ A ↔ □ ¬ A 

• Temporal operator sequence 

– ◊ □ A 

– □ ◊ A 



What is temporal logic useful for? 

• When proving safety property (e.g. mutual exclusion) we 

used invariants like ¬ (p4 ∧ q4) 

• These are no use for liveness properties (e.g. freedom 

from starvation) 

– We need to reason about progress: if process is in state satisfying formula A, it 

must progress to state satisfying B: 

– In temporal logic: A → ◊B 

• We need a basic understanding of temporal logic to be 

able to use model checking tools 



Temporal logic at work 

• Consider some safety and liveness properties for our solutions to the 

critical section problem: 

Critical section problem – Dekker’s algorithm 



loop forever 

p1: non-critical section 


p3: 

p4: 

while wantq 

if turn = 2 


p6: await turn = 1 


p8: > 

p9: turn ← 2 


p 

loop forever 

q1: non-critical section 


q3: 

q4: 

while wantp 

if turn = 1 


q6: await turn = 2 


q8: > 

q9: turn ← 1 


q 

• Mutual exclusion (safety)? 

• Freedom from starvation for p (liveness)? 

• Freedom from deadlock (liveness)? 



Model Checking 

• “Model checking is an automated technique that, given a finite-state model of a system 

and a logical property, systematically checks whether this property holds for (a given 

initial state in) that model.” [Clarke & Emerson 1981]* 

◾ A safety property asserts that nothing bad happens (e.g. no deadlocked states). 

◾ A liveness property asserts that something good will eventually happen (e.g. always normal 

termination). 

E. M. Clarke and E. A. Emerson. Design and synthesis of synchronization skeletons using branching time temporal logic. In Logic of Programs: Workshop, Yorktown 

Heights, NY, May 1981, volume 131 of LNCS. Springer, 1981 

◾ Clarke & Emerson (CMU) and Joseph Sifakis (Grenoble) won the ACM Turing Award 2007 for their work on Model Checking 

◾ Based on: 

http://ls1-www.cs.uni-dortmund.de/~tick/Lehre/SS06/MC/Spin-1.pdf & 

http://ls1-www.cs.uni-dortmund.de/~tick/Lehre/SS06/MC/Spin-2.pdf 

136 



Promela 

• Promela [Protocol/Process Meta Language is a modelling language, not a programming 

language. 

• A Promela model consist of: 

◾ type declarations 

◾ channel declarations // we won’t be using these 

◾ global variable declarations 

◾ process declarations 

◾ [init process] 

initialises variables and 

starts processes 

mtype, constants, 

typedefs (records) 

• A Promela model corresponds to a finite transition system, so: 

◾ no unbounded data / channels / processes / process creation 

- simple vars 

- structured vars 

- vars can be accessed 

by all processes 

behaviour of the processes: 

local variables + statements 

137 



Process (1) 

• A process is defined by a proctype definition 

• It executes concurrently with all other processes, independently of speed or 

behaviour 

• A process communicates with other processes: 

◾ using global variables 

◾ using channels 

• There may be several processes of the same type. 

• Each process has its own local state: 

◾ the process counter (location within the proctype) 

◾ the contents of the local variables 

138 



Process (2) 

• A process type (proctype) 

consists of 

◾a name 

◾a list of formal parameters 

◾local variable declarations 

◾the body 

proctype Sender(byte in; byte out) { 

bit sndB; 

do 

:: out==10 -> 

in=4; 

if 

:: sndB == 1 -> sndB = 1-sndB 

:: else -> skip 

fi 

od 

139 



Process (3) 

• Processes are created using the run 

statement (which returns the 

process id). 

• Processes can be created at any 

point in the execution. 

• Processes start executing after the 

run statement. 

• Processes can also be created and 

start running by adding active in 

front of the proctype declaration. 

active [2] proctype P() { 

byte i = 1; 

byte temp; 

do 

} 

:: ( i > TIMES ) -> break 

:: else -> 

temp = n; 

n = temp + 1; 

i++ 

od; 

finished++; /* Process terminates */ 

140 



SPIN Hello World Example 

SPIN = Simple Promula Interpreter 

/* A "Hello World" Promela model for SPIN. */ 

active proctype Hello() { 

printf("Hello process, my pid is: %d\n", _pid); 

} 

init { 

int lastpid; 

printf("init process, my pid is: %d\n", _pid); 

lastpid = run Hello(); 

printf("last pid was: %d\n", lastpid); 

lastpid = run Hello(); 

printf("last pid was: %d\n", lastpid); 

} 

$ spin -n2 hello.pr 

init process, my pid is: 1 

last pid was: 2 

Hello process, my pid is: 0 


last pid was: 3 


4 processes created 

141 



Promela Variables 

• Basic types 

◾ bit e.g. turn=1; range: [0..1] 

◾ bool e.g. flag; [0..1] 

◾ byte e.g. counter; [0..255] 

◾ short e.g. s; [-2 15 .. 2 15 –1] 

◾ int e.g. msg; [-2 31 .. 2 31 –1] 

• Default initial value of basic variables (local and global) is 0. 

• Most arithmetic, relational, and logical operators of C/Java are supported, 

including bitshift operators. 

142 



Promela Variables (2) 

• Arrays 

◾ Zero-based indexing 

• Records (“structs” in C/Java) 

◾ typedefs 

typedef Record { 

short f1; 

byte f2; 

} 

143 



Statements 

• A statement is either 

◾ executable: the statement can be executed immediately. 

◾ blocked: the statement cannot be executed. 

• An assignment is always executable. 

• An expression is also a statement; it is executable if it evaluates to non-zero. E.g. 

◾ 2 < 3 always executable 

◾ x < 27 only executable if value of x is smaller 27 

◾ 3 + x executable if x is not equal to –3 

144 



Statements (2) 

• The skip statement is always 

executable. 

◾ it “does nothing”, only changes 

the process counter 

• A run statement is only 

executable if a new process can 

be created (remember: the 

number of processes is 

bounded). 

int x; 

proctype Aap() 

{ 

int y=1; 

skip; 

run Noot(); 

x=2; 

x>2 && y==1; 

skip; 

} 

• A printf statement is always 

executable (but not effected 

during verification). 

145 



Statements (3) — assert 

• Format: assert(); 

• 

• 

The assert statement is always executable. 

If evaluates to zero, SPIN will exit with an error, as the 

has been violated. 

• Often used within Promela models, to check whether certain 

properties are valid in a state. 

146 



If Statement 

if 

:: (n % 2 != 0) -> n=1 

:: (n >= 0) -> n=n-2 

:: (n % 3 == 0) -> n=3 

:: else -> skip 

fi 

• Each :: introduces an alternative followed by convention with a guard statement 

◾ if the guard is executable, then the alternative is executable, and one executable 

alternative is non-deterministically chosen. 

◾ The optional else becomes executable if none of the other guards are executable. 

• If no guard is executable, the if statement blocks. 

147 



Do Statement 

• Same as the If statement, but it repeats the choice at the end. 

• Use the break statement to move on to the next sequential statement. 

do 

:: choice1 -> stat1.1; stat1.2; stat1.3; … 

:: choice2 -> stat2.1; stat2.2; stat2.3; … 

:: … 

:: choicej -> break; 

:: choicen -> statn.1; statn.2; statn.3; … 

od; 

148 



Atomic Statement 

atomic { stat1; stat2; ... statn } 

• An atomic{} statement can be used to group statements into an atomic 

sequence; 

• all statements are executed in a single sequence (no interleaving with 

statements of other processes), though each step is taken. 

• The statement is executable if stat1 is executable 

• If a stat i (with i>1) is blocked, the “atomicity token” is temporarily lost and 

other processes may do a step. 

149 



d_step (d = deterministic?) 

d_step { stat1; stat2; ... statn } 

• A d_step is a more efficient version of atomic: 

◾No intermediate states are generated and stored. 

◾It may only contain deterministic steps. 

• It is a run-time error if stat i (i>1) blocks. 

150 



Process Execution / Evaluation Semantics 

• Promela processes execute concurrently. 

◾ Non-deterministic scheduling of the processes. 

• Processes are interleaved (statements of different processes do not occur at the 

same time). 

◾ exception: rendezvous communication. (We’re not using this). 

• All statements are atomic; each statement is executed without interleaving with 

other processes. 

• Each process may have several different possible actions enabled at each point 

of execution. 

◾ one choice is made, non-deterministically. 

151 



Model Checking 

• Model checking tools automatically verify whether a property holds in a given 

(finite-state) model of a system. 

• Safety Properties 

◾ “Something bad never happens.” 

• SPIN tries to find a path to the bad thing; if not found, the property is satisfied. 

• Liveness Properties 

◾ “Something good always happens eventually.” 

• SPIN tries to find an infinite loop in which the good thing doesn’t happen; if not 

found, the property is satisfied. 

152 



The Closed World Assumption 

• The model seeks to establish the truth of something by trying 

exhaustively and failing to prove the negation of it. 

◾e.g. to prove that mutex holds, it tries to prove that it doesn’t 

hold. If it fails to do so, it is taken as proof that the mutex holds. 

• This only corresponds to what we normally understand to be 

“proof” if it is assumed that the model checker knows 

everything (i.e. can prove everything provable) about the system 

-- it’s called the “Closed World Assumption.” 

153 



Related: Negation-as-Failure 

• If you fail to prove that A is true, then with negation as failure, 

this is taken as proof that (¬ A) is true. 

◾Again, this doesn’t correspond with what we “normally” 

understand as proof. 

◾To make it correspond, we must invoke the CWA. 

154 



Process memory management 

• In a multi-programming environment processes share available physical memory 

◾ The aggregate memory requirements of processes executing on a system often exceed the available physical 

memory capacity 

◾ How does the programmer know where his/her program will be located in memory? 

• Solution: use another memory device (e.g. a hard disk) to increase memory capacity 

◾ A “swap device” or “page file” 

◾ Treat the memory used by a process as a set of fixed size memory chunks, called pages 

◾ Simplifies moving memory contents to/from the swap device 

◾ Leads to fragmentation: process’s memory is no longer contiguous in physical memory 

◾ Not only does the programmer not know where his/her program will be located, but now it can also move 

over time 

155 



Relocation and non-contiguity 

0 

0 

0 

0 

0 

0 

1 

1 

1 

1 

1 

1 

2 

2 

2 

2 

2 

2 

3 

3 

3 

3 

3 

3 

4 

4 

4 

4 

4 

4 

5 

5 

5 

5 

5 

5 

6 

6 

6 

6 

6 

6 

7 

7 

7 

7 

7 

7 

8 

8 

8 

8 

8 

8 

9 

9 

9 

9 

9 

9 

10 

10 

10 

10 

10 

10 

11 

11 

11 

11 

11 

11 

12 

12 

12 

12 

12 

12 

13 

13 

13 

13 

13 

13 

14 

14 

14 

14 

14 

14 

Load A Load B Load C Swap out B Load D 

156 



Virtual memory 

• Give each process its own virtual address space 

◾ Divide the space into fixed-size pages (e.g. 4KB or 212B) 

• Programs refer to addresses in their own virtual memory space – virtual addresses 

• “On-the-fly” conversion of virtual addresses into physical addresses, which are applied to physical 

memory 

32 bit address 

20 bits 12 bits 

Virtual address 

Physical address 

virtual page number 

translated by 

MMU 

physical page frame number 

page offset 

page offset 

unchanged 




• The Memory Management Unit (MMU) is integrated into modern CPUs 

• If we use 32-bit addresses (physical and virtual) and if the address space is divided into 4KB pages 

◾ The total addressable memory is 232 = 4GB 

◾ Each page contains 212 bytes (4KB) requiring a 12-bit offset 

◾ There are 220 (1,048,576) 4KB pages, each with a 20-bit page number 

• The size of the virtual address space is typically much larger than the physical address space 

◾ Every virtual page won’t be mapped to a physical page 

◾ Some virtual pages may not be used 

◾ Some pages may be mapped to a swap device or page file 

• Per-process virtual address space 

◾ Each process has it’s own virtual address space 

158 




0 

0 

process 1 

2 32 0 

physical 

memory 

process 2 

page 

frames 

2 32 0 

x 

process n 

paging 

disk 

2 32 

159 



Memory management requirements and VM 

• Requirements 

◾ Location 

• In a multiprogramming environment, processes (and the operating system) need to share physical memory 

• Programs must be paged in and out of memory 

• Programmers have no way of knowing where in physical memory their processes will be located, and processes won’t 

be continuous 

• Virtual memory gives each process it’s own contiguous virtual memory space, within which the programmer works 

◾ Protection 

• In a multiprogramming environment, a user process must be prevented from interfering with memory belonging to 

other processes and the operating system itself 

• This protection must be implemented at run-time 

• Each process only has access to its own virtual memory space, which should never map to the physical memory of 

another process (except under specific circumstances!) 

160 



Memory management requirements and VM 

◾ Sharing 

• Protection must be flexible enough to allow portions of memory to be shared between processes 

• We can map the virtual pages of different processes to the same physical memory page frame (or same frame on disk) 

◾ Logical Organization 

• Programs are organised as modules with different properties 

• Executable code, data, shared data 

• Assign properties to virtual memory pages 

◾ Physical Organization 

• The programmer should be isolated from implementation of the memory hierarchy (e.g. swapping) 

• The programmer shouldn’t be concerned with the amount of physical memory available 

• The virtual memory space hides details from the programmer 

161 



Virtual memory implementation 

• Each process has its own page table 

◾ Used to map virtual pages to physical page frames 

◾ Page tables are also stored in memory 

• To translate a virtual page number to a physical page frame number 

◾ Use the virtual page number as an index to the page table 

◾ Read the physical page frame number from the table 



page offset 



page offset 

162 



E.g. Virtual memory implementation 

• Page table format (32-bit addresses and 4KB pages) 

0 

32 bits 


i 

physical page 

number 

status 

page table entry (PTE) 

2 20 - 1 

Status: e.g. valid, 

protection level, 

modified, referenced 

163 



Multi-level page tables 

• Assuming 32-bit addresses and 4KB page size 

◾ 1,048,576 page table entries x 4 bytes each = 4MB 

◾ i.e. every process requires a 4MB page table!! 

◾ wasteful, when you consider that most processes will use only a small portion of the virtual address space 

◾ most of the page table will be unused 

• Solution 

◾ A multi-level page table scheme 

32 bit address 


12 bits 


1 st index 2 nd index page offset 

164 





1 st index 2 nd index 

page offset 

e.g. a twolevel 

page 

table scheme 



page offset 

165 




• In a two-level page table scheme 

◾ One primary page table 

◾ As many secondary page tables as needed 

◾ Secondary page tables are created (and removed) as needed 

◾ Depends on how much of the virtual memory space is required by the process 

◾ In the preceding example, each page table was 4KB in size so each page table fitted in exactly one page frame 

◾ Different schemes will use different size bit-fields for 1st and 2nd indices 

◾ Different schemes will use three (or more?) levels of page tables 

◾ More efficient than a single-level scheme 

◾ The page offset still remains un-translated. 

• What is the total size of all page tables in the preceding example, if two primary PTEs are used? 

166 



Typical process memory layout 

memory 

page 

0 

code 

code 

code 

primary 

page table 

code 

code 

code 

data 

memory 

page 

data 

1022 invalid 

page table 

entries 

1020 invalid 

page table 

entries 

memory 

page 

memory 

page 

stack 

2 32 stack 

process virtual 

address space 

1022 invalid 

page table 

entries 

stack 

stack 

memory 

page 

memory 

page 

167 



Page Faults 

• When the MMU accesses a PTE, it checks the Valid bit of the status field to determine if the entry is 

valid: 

◾ if V==0 and a primary PTE is being accessed 

then a secondary page table has not been allocated physical memory 

◾ if V==0 and a secondary PTE is being accessed 

then no physical memory has been allocated to the referenced page 

◾ in either case, a page fault occurs 

• The OS is responsible for handling page faults by … 

◾ … allocating a page of physical memory for a secondary page frame 

◾ … allocating a page of physical memory for the referenced page 

◾ … updating page table entries 

◾ … writing a replaced page to disk if it is dirty 

◾ … reading code or data from disk (another thread will be scheduled pending the I/O operation) 

◾ … signalling an access violation 

◾ ... retrying to execute the faulting instruction 

168 



Translation look aside buffer 

• Each virtual-to-physical memory address translation requires 1 memory access for each level of page 

tables 

◾ 2 memory accesses in a 2-level scheme 

• To reduce the number of memory access required for virtual-to-physical address translation, the MMU 

uses a Translation Look-Aside Buffer (TLB) 

◾ An on-chip cache 

◾ Stores the results of the m most recent address translations 

0 


secondary page table entry 

m-1 

169 



Translation Look-Aside Buffer 

• Before walking the page tables to translate a virtual address to a physical address… 

◾ … the MMU checks each entry in the TLB 

• If the virtual page number is found, the cached secondary PTE is used by the MMU to translate the 

address … 

◾ … and there is no need to walk the page tables in memory 

• If a TLB match is not found … 

◾ … The MMU walks the page tables and locates the required PTE 

• The least recently used (LRU) TLB entry is now replaced with the current virtual page number and the 

PTE from the secondary page table 

• What are the TLB implications of a context switch? 

170 



Page fault handling 

Start 

Access page table 

O/S reads page from disk 

no 

Page in main 

memory? 

Memory full? 

no 

yes 

Page tables updated 

yes 

Update TLB 

Page tables updated 

page fault handler 

CPU generates physical address 

171 



Memory-management: the OS perspective 

• What are we interested in from an OS perspective? 

◾ Page fault handling 

• The goal of the operating system is to attempt to minimise the occurrence of page faults, which are 

expensive 

◾ Need to decide which physical memory page to use 

◾ Need to perform I/O 

◾ Another process needs to be scheduled to run during the I/O, resulting in a context switch 

• We will look at several policies used by the OS to perform memory management 

◾ The key questions are: 

• When should a page be loaded? 

• Where (in physical memory) should it be loaded? 

172 



Fetch policy 

• When should a page be loaded? 

◾ Two alternatives 

• Demand Paging 

◾ Pages are loaded into memory only when they are first referenced 

◾ When a process is started, there will be a number of page faults in quick succession 

◾ Locality of reference: over a short period of time, most memory references are to a small number of pages 

• The pages references changed relatively slowly over time 

• Prepaging (performed in addition to demand paging) 

◾ Takes advantage of the characteristics of disk devices 

• Seek times and rotational latency 

◾ If a number of pages are contiguous in secondary storage, it is more efficient to load the contiguous pages, 

even though they haven’t been referenced yet 

173 



Page replacement policy 

• Of the page frames available for replacement, which one should be replaced when a page fault occurs? 

• Basic scheme 

◾ A page fault occurs 

◾ Find a free frame 

◾ If there was a free frame, then use it 

◾ Otherwise if all the frames are used 

• select a victim frame using a page replacement policy 

• write the victim frame to disk and update the page table entries accordingly 

◾ Read the new page from disk into the selected page frame 

◾ Allow the faulting process to resume 

• Note 

◾ Replacing a victim page frame potentially requires both a read and a write 

174 




• A page replacement policy is required when there are no free pages and we need to select a page to 

replace 

• Optimal algorithm 

◾ Select the page for which the time until the next reference is furthest away … 

◾ Obviously, we cannot implement this policy without prior knowledge of future events 

◾ However, it is a useful policy against which more practical policies can be measured 

• Least Recently Used (LRU) 

◾ Replace the page in memory that was referenced furthest back in time 

◾ Exploits locality of reference 

◾ Near-optimal performance 

◾ Disadvantage: very expensive to implement 

175 




• Least Recently Used (LRU) (Cont’d) 

◾ Counter: 

• Associate a timestamp variable with each page table entry 

• Implement a logical clock that is incremented on every memory access 

• Whenever we access a memory page, we update the timestamp in the page table entry with the current logical clock 

value 

• To replace a page we need to search the page tables to find the least recently used page 

• Updates are cheap but searching for a replacement is very expensive 

◾ Stack 

• Maintain a stack as a doubly linked list of page table entries 

• When a page is referenced, move it from its current position in the stack to the top of the stack 

• Always replace the page at the bottom of the stack 

• Updates are expensive but searching for a victim page is cheap 

176 




• First-In-First-Out (FIFO) 

◾ Replace pages in a round-robin order 

◾ Very efficient to implement – maintain a pointer to the next page to be replaced 

◾ Assumes that the page loaded into memory furthest back in time is also the page accessed furthest back in 

time 

◾ Bad assumption, we might have a page that is accessed frequently for a long period of time 

• This page will be repeatedly loaded and unloaded 

• Clock algorithm (or second-chance algorithm) 

◾ Performs better than FIFO but is not as inefficient to implement as LRU 

◾ Conceptually, candidate pages for replacement are arranged in a circular list 

◾ Each page has an associated use bit (also called reference bit) 

• Set to 1 when page is loaded or subsequently accessed 

177 




• Clock algorithm (continued …) 

◾ To find a page for replacement 

• Proceed around the list until a page with a use=0 is found 

• Every time we pass over a page with use=1, set use=0 

• If all pages have use=1, we will eventually arrive back where we started, but we will have set use=0 

◾ Efficient to implement 

◾ Similar to FIFO, except that any page with use=1 will be ignored, unless there is no page with use=0 

• Clock algorithm with modified bit 

◾ As well as use bits, we use pages’ modified bits 

◾ Algorithm: 

• First pass: look for use=0, modified=0, don’t set use=0 

• Second pass: look for use=0, modified=1, set use=0 

• Third pass: As before, we are back at our starting position, but use will be set to 0 this time 

◾ Why? It’s cheaper to replace pages that don’t need to be written first 

178 



Clock Algorithm 

179 



Resident set management 

• How many pages can each process have resident in memory? 

• Factors affecting decision 

◾ If we allocate less memory to each process, we can fit more processes into memory, thus increasing the 

probability that there will be at least one process ready to be executed 

◾ If each process has only a small number of pages resident in memory, we will have more page faults 

◾ If we increase the number of resident pages for a process beyond some threshold, the performance increase 

will become negligible (locality of reference) 

• Two types of policy are used 

◾ Fixed allocation – every process has a fixed number of pages in memory 

◾ Variable allocation – allocation varies over the lifetime of the process 

180 




• Variable allocation 

◾ Processes suffering from many page faults can be allocated more page frames 

◾ Processes with few page faults can have their allocation reduced 

◾ This appears to be more powerful than fixed allocation 

• With fixed allocation, we are stuck with the decision made a load-time – the ideal resident set size may vary depending 

on input to the program 

• And how to we calculate the working set size in the first place 

• However, it is also more expensive to implement 

• Variable allocation raises another question … 

◾ Should the set of candidate pages for replacement be restricted to the pages already allocated to the process 

that caused the page fault? 

◾ Two choices: 

• Variable allocation – global scope 

• Variable allocation – local scope 

181 




• Variable allocation – global scope 

◾ The operating system maintains a list of free page frames 

◾ When a fault occurs, a free frame is added to the resident set of the process 

◾ When there are no free pages available, the page selected for replacement can belong to any process 

◾ This will result in a reduction in the working set size for the process whose page was replaced – might be 

unfair, there is no way to discriminate between processes 

• Variable allocation – local scope 

◾ When a process is loaded, it is allocated some number of page frames based, for example, on application type 

◾ When a page fault occurs, a page is selected for replacement from the resident set of the process that caused 

the fault 

◾ Occasionally, the operating system will re-evaluate the number of page frames allocated to each process 

182 




Local Replacement 

Global Replacement 

Fixed Allocation 

• 

Number of frames allocated to process is 

fixed 

• 

Page to be replaced is chosen from among 

pages allocated to the faulting process 

• 

Not possible 

Variable 

Allocation 

• 

Number of frames allocated to process will 

vary according to working set requirements 

• 

Page is chosen from among pages allocated 

to faulting process 

• 

Page to be replaced is chosen 

from among all available page 

frames in main memory 

• 

This causes the size of the 

resident set to vary 

183 



The Working Set 

◾ The Working Set of a process is the list of pages it has referenced in the last ∆ references, proposed by 

Denning. 

◾ Thus, the Working Set is a “windowed” snapshot of a process’ paging referencing. 

◾ The Working Set Model idea is that processes should have their working set resident in physical memory to be 

able to function efficiently. 

• If too few pages allocated (i.e. less than the working set), a process will spend lots of time page-faulting. 

• If too many pages are allocated, (i.e. more than the working set), other processes might be deprived of the physical 

memory they need. 

◾ If there isn’t enough memory for the working sets of all the processes, some processes are temporarily 

removed from the system. 

◾ Only difficulty is keeping track of the working set. 

184 




Δ 

Working Set Size 

Transient Transient Transient Transient 

Stable Stable Stable Stable 

185 




• How do we decide on a resident set size for a process? 

◾ We could monitor the working set of each process and periodically remove from the resident set those pages 

not in the working set 

• Problems 

◾ Past doesn’t predict future – size and membership of working set will change over time 

◾ Measurement of working set is impractical 

◾ Optimal value for ∆ is unknown 

• Solution 

◾ We can approximately detect a change in working set size by observing the page fault rate 

◾ If the page fault rate is below some minimum threshold, we can release allocated page frames for use by other 

processes 

◾ If the page fault rate is above some maximum threshold, we can allocate additional page frames to the process 

186 




187 



Cleaning policy 

• Determines when a modified page should be written to secondary memory 

• Two approaches 

◾ Demand cleaning 

• Pages are written to secondary memory only when they are selected for replacement 

◾ Precleaning 

• Write pages periodically, before they need to be replaced 

• Pages can be written in batches to increase efficiency 

• Neither approach is ideal 

◾ If pages are precleaned long before they are replaced, there is a high probability they will have been modified 

again 

◾ Demand cleaning results in a longer delay when replacing pages 

188 



Cleaning policy 

• Page buffering 

◾ A better solution for both page replacement and cleaning 

◾ When a page is replaced, instead of replacing it immediately, place it on either an unmodified list or a modified 

list 

◾ Pages on the modified list can periodically be written out to secondary memory and moved to the unmodified 

list 

◾ Pages on the unmodified list can be reclaimed if they are referenced again before they are allocated to another 

process 

• Notes 

◾ “Moving” a page to a modified or unmodified list does not result in copying of data. 

◾ Instead, the PTE for the page is removed from the page table and placed on one of the lists 

◾ This approach can be combined with FIFO replacement to improve the performance of FIFO replacement 

while remaining efficient to implement 

189 



Load control 

Processor utilisation 

Multiprogramming level 

190 



Load control 

• We can use a few different policies 

◾ Only allow processes whose resident set is sufficiently large to execute 

◾ Research has shown that when the mean time between faults is equal to the mean time required to process a 

fault, processor utilisation will be maximised 

• Suspending processes 

◾ To reduce the degree of multiprogramming, we need to suspend (swap out) one or more resident processes – 

but which ones do we swap? 

• Lowest priority process 

• Faulting process 

• Last process activated 

• Process with smallest resident set size 

• Largest process 

191 



Operating system scheduling (single CPU) 

• Only one process can execute at a time on a single processor system 

◾ A process is typically executed until it is required to wait for some event 

• e.g. I/O, timer, resource 

◾ When a process’ execution is stalled, we want to maximise CPU utilization by executing another process on 

the CPU 

• CPU I/O burst cycle 

◾ Processes alternate between bursts of CPU and I/O activity 

◾ CPU burst times have an exponential frequency curve with many short bursts and very few long bursts 

• CPU scheduler 

◾ When the CPU becomes idle, the operating system must select another process to execute 

◾ This is the role of the short-term scheduler or CPU scheduler 

192 



Process state transitions 

• Process state transitions 

◾ Only one process can be in the running state on a single processor at any time 

◾ Multiple processes may be in the waiting or ready states 

pre-emptive 

pre-emptive and nonpre-emptive 

new 

admitted 

exit 

terminated 

ready 

interrupt 

dispatch to CPU 

running 

event 

(e.g. I/O completion) 

waiting 

wait 

(e.g.for I/O completion) 

193 



CPU Scheduler 

• CPU scheduler (continued) 

◾ Candidate processes for scheduling are those processes that are in memory and a ready to execute 

◾ Candidate processes are stored on the ready queue 

◾ The ready queue is not necessarily a FIFO queue, but depends on the implementation of the scheduler 

• FIFO queue, priority queue, unordered list, … 

• Scheduling may be performed in any of these situations 

1. When a process leaves the running state and enters the waiting state, waiting for an event (e.g. completion of 

an I/O operation) 

2. [PREEMPTIVE] When a process leaves the running state and enters the ready state ( e.g. when an interrupt 

occurs) 

3. [PREEMPTIVE] When a process leaves the waiting state and enters the ready state 

4. When a process terminates 

194 



Preemptive and nonpreemptive scheduling 

• Scheduling must be performed in cases 1 and 4 

◾ If scheduling only takes place in cases 1 and 4, then the scheduling is non-preemptive 

◾ Otherwise the scheduling is preemptive 

• With a non-preemptive scheme 

◾ Once a process has entered the running state on a CPU, it will remain running until it relinquishes the CPU to 

another process 

• Preemptive scheduling incurs a cost 

◾ Access to shared data? 

◾ Synchronization of access to kernel data structures? 

195 



Scheduling Algorithms 

First-Come-First- 

Served (FCFS) 

Shortest Job First Priority Round Robin 

Non-Preemptive ✔ Fragile Fragile This is FCFS 

Pre-Emptive ? ✔ ✔ ✔ 

• FCFS also is First In First Out (FIFO) 

• Non-Preemptive Scheduling is also called Cooperative Scheduling and relies on the processes to be 

“well-behaved” and to voluntarily relinquish the processor. Thus, it’s always fragile! 

• The advantage of Cooperative Scheduling is that, because the processes are designed to relinquish the 

processor, they can be designed to minimise the overhead of doing so. This is often a very big advantage 

in specialised situations, e.g. inside the kernel of an OS, where efficiency is paramount and processes can 

be trusted. 

196 



Scheduling algorithms 

• First-Come First-Served (FCFS) [non-preemptive] 

◾ The process that requests the CPU first is the first to be scheduled 

◾ Implemented with a FIFO ready queue 

◾ When a process enters the ready state, it is placed at the tail of the FIFO ready queue 

◾ When the CPU is free and another process must be dispatched to run, the process at the head of the queue is 

dispatched and the running process is removed from the queue 

◾ The average waiting time under FCFS scheduling can be quite long and depends on the CPU burst times of the 

processes 

◾ Consider three processes: P1, P2 and P3 that appear on the FCFS ready queue in the order P1, P2 and P3 and 

with burst times of 24, 3 and 3 milliseconds respectively 

P 1 P 2 P 3 

0 24 27 

◾ Average waiting time = (0 + 24 + 27) / 3 = 17 ms 

197 




• First-Come First-Served (FCFS) (continued) 

◾ Now consider the same processes, but in the order P2, P3, P1 on the ready queue 

P 2 P 3 

0 3 

6 

P 1 

◾ Average waiting time = (0 + 3 + 6) / 3 = 3 ms 

◾ Another example: one CPU bound process and many I/O bound processes: 

• The CPU bound process will obtain and hold the CPU for a long time, during which the I/O bound processes complete 

their I/O and enter the ready queue 

• The CPU bound process eventually blocks on an event, the I/O bound processes are dispatched in order and block 

again on I/O 

• The CPU now remains idle until the CPU bound process is again scheduled and the I/O bound processes again spend a 

long time waiting 

198 




• Shortest-Job-First [preemptive or non-preemptive] 

◾ Given a set of processes, the process with the shortest next CPU burst is selected to execute on the CPU 

◾ Optimizes minimum average waiting time 

◾ There is an obvious problem with this – how do we know how long the next CPU burst will be for each 

process? 

◾ We can use past performance to predict future behaviour 

• Estimate the next CPU burst time as an exponential average of the lengths of previous CPU bursts 

• Let tn be the length of the n th CPU burst for a process and let τn+1 be our estimated next CPU burst time 

τn+1 = αtn+(1- α)τn , α ≤ 0 ≤ 1 

• If α = 0, the current prediction is equal to the last prediction 

• if α = 1, then τn+1 = αtn and the next CPU burst time is estimated to be the length of the last CPU burst time 

• We need to set τ0 to a constant value 

199 




• Shortest-Job-First [preemptive or non-preemptive] 

◾ To see how the value for τn+1 is calculated based on past history, we can expand the formula, substituting for τn 

τn+1 = αtn + (1- α) αtn-1 + … + (1- α) j αtn-j + … + (1- α) n+1 τ0 

α is typically given the value 0.5 

◾ SJF can be either preemptive or non-preemptive 

• Preemptive SJF will preempt the currently executing process if a process joins the ready queue with a smaller next CPU 

burst time 

• Non-preemptive SJF scheduling will allow the currently executing process to complete its CPU burst before scheduling 

the next process 

200 




• Priority scheduling [preemptive or non-preemptive] 

◾ Shortest-Job-First is a special case of a more general priority-based scheduling scheme 

◾ Each process has an associated priority 

◾ The process with the highest priority is executed on the CPU 

◾ Processes with the same priority are executed in the order in which they appear on the ready queue (FCFS 

order) 

◾ What do we mean by high and low priority 

• We’ll assume high-priority processes have lower priority values than lower priority processes 

• Doesn’t matter 

◾ The priority of a process can be defined either internally or externally 

• Internally defined priories are based on measurements associated with the process, such as the ratio of I/O burst times 

to CPU burst times, the estimated next CPU burst time, time since last scheduling 

• Externally defined priorities are based on properties external to the operating system: user status, wealth, political 

affiliation, … 

201 




• Priority scheduling [preemptive or non-preemptive] 

◾ Like SJF scheduling, priority scheduling can be either preemptive or non-preemptive 

• Preemptive: the currently executing process is preempted if another higher priority process arrives on the ready queue 

• Non-preemptive: the currently executing process is allowed to complete its current CPU burst 

◾ Priority scheduling has the potential to starve low priority processes of access to the CPU 

◾ A possible solution is to implement an aging scheme 

• Periodically decrement the priority value of waiting processes (increasing their priority) 

202 




• Round-Robin Scheduling 

◾ First-Come, First-Served with preemption 

◾ Define a time quantum or time slice, T 

◾ Every T seconds, preempt the currently executing process, place it at the tail of the ready queue and schedule 

the process at the head of the ready queue 

◾ New processes are still added to the tail of the ready queue when they are created 

◾ The currently executing process may relinquish the CPU before it is preempted (e.g. by performing I/O or 

waiting for some other event) 

• The next process at the head of the ready queue is scheduled and a new time quantum is started 

◾ For a system with n processes, there is an upper limit on the time before a process is given a time quantum on 

the CPU 

◾ (n – 1) q 

203 




• Round-Robin Scheduling 

◾ The performance of Round-Robin scheduling depends on the size of the time quantum, T 

◾ For very large values of T, the performance (and behaviour) of Round-Robin scheduling approaches that of 

FCFS 

◾ As T approached zero, processes execute just one instruction per quantum 

◾ Obviously for very small values of T, the time taken to perform a context switch needs to be considered 

• T should be large with respect to the time required to perform a context switch 

204 



Example 

Process Arrival Time Next Burst Time 

Priority 

(Lower is Better) 

P1 0 8 2 

P2 1 4 4 

P3 2 9 1 

P4 3 5 3 

• Scheduling goals 

◾ Fast response time 

• Look at Waiting Time (i.e. latency) and Turnaround Time (i.e. time from arrival to end of burst). 

◾ High throughput 

• Avoid thrashing, avoid high level of context switches 

◾ Fairness 

• If we implement priorities, be careful to ensure starvation is avoided. 

205 



Example — FCFS 

FCFS Arrival Time Next Burst Time Waiting Time Turnaround Time 

P1 0 8 0 8 

P2 1 4 8-1 = 7 12-1 = 11 

P3 2 9 

P4 3 5 

206 




• Multi-level queue scheduling 

◾ Often we can group processes together based on their characteristics or purpose 

• system processes 

• interactive process 

• low priority interactive processes 

• background processes 

system processes 

interactive processes 

low priority interactive processes 

background processes 

207 




• Multi-level queue scheduling 

◾ Processes are permanently assigned to these groups and each group has an associated queue 

◾ Each process group queue has an associated queuing discipline 

• FCFS, SJF, priority queuing, Round-Robin, … 

◾ Additional scheduling is performed between the queues 

• Often implemented as fixed-priority pre-emptive scheduling 

◾ Each queue may have absolute priority over lower priority queues 

• In other words, no process in the background queue can execute while there are processes in the interactive queue 

• If a background process is executing when an interactive process arrives in the interactive queue, the background 

process will be preempted and the interactive process will be scheduled 

◾ Alternatively, each queue could be assigned a time slice 

• For example, we might allow the interactive queue 80% of the CPU time, leaving the remaining 20% for the other 

queues 

208 




• Multi-level feedback queue scheduling 

◾ Unlike multi-level queue scheduling, this scheme allows processes to move between queues 

◾ Allows I/O bound processes to be separated from CPU bound processes for the purposes of scheduling 

◾ Processes using a lot of CPU time are moved to lower priority queues 

◾ Processes that are I/O bound remain in the higher priority queues 

◾ Processes with long waiting times are moved to higher priority queues 

• Aging processes in this way prevents starvation 

◾ Higher priority queues have absolute priority over lower priority queues 

• A process arriving in a high-priority queue will preempt a running process in a lower priority queue 

T = 8 

T = 16 

FCFS 

209 




• Multi-level feedback queue scheduling 

◾ When a process arrives on the ready queue (a new process or a process that has completed waiting for an 

event), it is placed on the highest priority queue 

◾ Processes in the highest priority queue have a quantum of 8ms 

◾ If a high priority process does not end its CPU burst within 8ms, it is preempted and placed on the next lowest 

priority queue 

◾ When the highest priority queue is empty, processes in the next queue are given 16ms time slices, and the 

same behaviour applies 

◾ Finally, processes in the bottom queue are serviced in FCFS order 

◾ We can change 

• number of queues 

• queuing discipline 

• rules for moving process to higher or lower priority queues 

210 



Multi-processor scheduling 

• Flynn’s taxonomy of parallel processor systems 

◾ Single instruction single data (SISD) 

◾ Single instruction multiple data (SIMD) 

• vector / array processor 

◾ Multiple instruction single data (MISD) 

• argument over precise meaning (pipelined processor ???) 

◾ Multiple instruction multiple data (MIMD) 

• shared memory (tightly coupled) 

• asymmetric (master/slave) 

• symmetric (SMP) 

• distributed memory (loosely coupled) 

• cluster 

211 



Multi-processor scheduling 

• Processor affinity 

◾ If a process can execute on any processor, what are the implications for cache performance? 

◾ Most SMP systems implement a processor affinity scheme 

• soft affinity: an attempt is made to schedule a process to execute on the CPU it last executed on 

• hard affinity: processes are always executed on the same CPU 

• Load balancing 

◾ Scheduler can use a common ready queue for all processors or use private per-processor ready queues 

◾ If per-processor ready queues are used (and no affinity or soft-affinity is used), then load-balancing between 

CPUs becomes an issue 

◾ Two approaches: 

• pull-migration: idle processors pull ready jobs from other processors 

• push-migration: load on each processor is monitored and jobs are pushed from overloaded processors to under-loaded 

processors 

◾ Load-balancing competes with affinity 

212 



Layered file I/O (1) 

Application 

Directory 

management 

File system 

Physical 

organisation 

Device I/O 

Hardware 

• The operating system modules or drivers responsible for 

performing I/O form a hierarchy, with a different view or 

abstraction of the underlying storage service or device 

presented at each level 

◾ Directory management: symbolic names and hierarchical directory 

structure 

◾ File system: logical layout of disk blocks and servicing of requests 

◾ Physical organization: logical block addresses are converted into 

physical addresses and device identifiers 

◾ Device I/O: Scheduling and control of I/O on physical devices 

213 



Layered file I/O (2) 

Application 

Directory 

management 

File system 

Software RAID 

Physical 

organisation 

Device I/O 

Hardware 

• Layers can be added or substituted to add functionality 

◾ As long as the layers adhere to interfaces 

• Example: Software RAID 

◾ We can implement a single logical volume on multiple disks to improve 

performance and/or reliability 

◾ A software RAID layer presents the same logical volume abstraction to 

the file system layer above 

◾ Logical block addresses at the software RAID level are translated into 

logical addresses of blocks within a partition on a disk device 

◾ The request is serviced as before at the physical organisation and 

device I/O levels 

214 



Disk access 

• Disks are slow 

◾ We need ways to improve the performance of disk I/O 

◾ Caching is one possibility, but this still doesn’t help us on the occasions when device I/O needs to be 

performed 

◾ How can the operating system improve disk I/O performance? 

• Aside: Disk I/O delays … 

◾ seek time: the head must be positioned at the correct track on the platter 

◾ rotational delay: the transfer cannot begin until the required sector is below the head (sometimes expressed 

at latency) 

◾ data transfer: the read or write operation is performed 

• Average access time: 

seek 

latency transfer 

215 



Access time example 

• Suppose we have a disk with these characteristics … 

◾ Rotational speed: 7,200 RPM (latency = 4.17ms) 

◾ Average seek time: 8.5 ms 

◾ 512-byte sectors 

◾ 320 sectors per track 

• Using these average delays, how long does it take to read 2560 sectors from a file? 

◾ Time to read one sector = 8.5 + 4.17 + 0.0261 = 12.6961 ms 

◾ Time to read 2560 sectors = 32.5 seconds (that’s slow) 

• However, if we assume the file is contiguous on disk 

◾ and occupies exactly 8 tracks 

◾ Time to seek to first track = 8.5 ms 

◾ Time to read track = 4.17 ms + 8.34 ms 

◾ Suppose seek time between tracks is 1.2 ms 

◾ Total read time = 8.5 + 4.17 + 8.34 + 7 x (1.2 + 4.17 + 8.34) = 117 ms 

216 



Disk scheduling 

• So, the order in which sectors are read has a significant influence on I/O performance 

◾ Most file systems will try to arrange files on disk so large portions of the file are contiguous 

◾ Below the file system level, even if files are not contiguous, the operating system or disk device driver can try 

to order operations so seek times are minimised 

• Disk scheduling algorithms 

◾ When a process needs to perform disk I/O, a request is issued to the operating system’s I/O manager 

◾ The operating system creates a descriptor for the operation 

◾ If there are no other pending requests (from the same or other processes) then the request can be scheduled 

immediately and performance is not an issue 

◾ If multiple disk accesses are queued up at the same time, the OS can improve I/O bandwidth and/or latency 

through sensible ordering of the queued I/O operations 

217 



Disk scheduling algorithms (1) 

• FCFS scheduling 

◾ The I/O request queue is follows the FIFO queuing discipline 

◾ Requests are serviced in the order in which they were submitted to the operating system’s I/O manager 

◾ Although the algorithm is fair, the distribution of requests across the disk means a significant proportion of the 

disk access time is spent seeking 

• SSTF scheduling 

◾ Shortest seek time first 

◾ Of the queued requests, select the one that is closest to the current disk head position (the position of the last 

disk access) 

◾ Reduces time spent seeking 

◾ Problem: Some requests may be starved 

◾ Problem: The algorithm is still not optimal 

218 




• SCAN scheduling 

◾ Starting from either the hub or the outer edge of the disk and moving to the other edge, service all the 

queued requests along the way 

◾ When the other edge is reached, reverse the direction of head movement and service the queued requests in 

the opposite direction 

◾ If a requests arrives in the queue just before the head reaches the requested track, the request will be serviced 

quickly 

◾ However, if a requests in the queue just after the head has serviced the requested position, the request may 

take a long time to be serviced (depending on the current head position) 

• Consider a request for a track at the hub that arrives just after the hub has been serviced 

• That request will not be serviced until the head has serviced the requests in both directions 

219 




• C-SCAN scheduling 

◾ Circular-SCAN scheduling 

◾ Similar to SCAN, but the worst case service time is reduced 

◾ Like SCAN, the head moves in one direction servicing requests along the way 

◾ However, unlike SCAN, instead of servicing requests in the opposite direction, the head is returned 

immediately to the opposite edge and starts servicing requests again in the same direction 

• SCAN and C-SCAN continuously move the head from one extreme of the disk to the other 

◾ In practice, if there are no further requests in the current direction, the head reverses its direction immediately 

◾ These modifications are referred to as the LOOK and C-LOOK scheduling algorithms 

220

Concurrent Systems II - Bad Request - Trinity College Dublin

Create successful ePaper yourself

Delete template?

Save as template?