Chapter 1:

Introduction

Lecture 2
Admin
● Prerequisites of COS122 and COS212
will be enforced

● Class representative nominations open

until today (4 Aug), 18h00.
Acknowledgement

● Some of the slides are taken from the companion

slides for “The Art of Multiprocessor Programming” by
Maurice Herlihy & Nir Shavit
Today’s Lesson
● Intro to Concurrency Concepts

● Mutual Exclusion
Processes and Threads
● Process:
● an instance of a program being executed.
● has its own address space, which can not be
accessed from other processes.
● inter-process communication possible through
sockets, pipes, semaphores, etc. (requires
effort)

● Thread:
● a separate line of execution (i.e. a sequence of
instructions) within a process.
● a process can have multiple threads, all of
which share its address space, file handles etc.
Problems of Concurrency
● The concurrency problems arise from the
scenario of concurrent computing, where the
execution of a program is conducted in
multiple processes (or threads)
simultaneously.

● By simultaneousness, the processes or

threads are not necessarily running
independently in different physical CPUs, but
more often they interleave in the same
physical CPU.
Race Condition
● Race condition: occurs when two or more
threads can access shared data and they try
to change it at the same time

● Difficult to reproduce and debug:

● The final output is non-deterministic – depends on
the execution order of instructions of different
threads
Race Condition
● Example: Bank Account
private int balance; //class member

public int withdraw(int amount) {

if (amount < balance) {
balance -= amount;
}
return balance;
}
● Initial balance: R500
● Two threads attempt to concurrently withdraw
money from the account (e.g. debit orders)
● Thread 1: withdraw R400
● Thread 2: withdraw R200
Race Condition
Race Condition
● Resolution: identify the critical section

public int withdraw(int amount) {

if (amount < balance) {
balance -= amount;
}
return balance;
}
A block of code where
shared variables can be
accessed
Race Condition
Program Correctness
● What does it mean for a program to
be correct?
● When there are no compilation errors
and warnings?
● When it produces the correct outputs for
our test cases?
● You’d need to test all possible inputs
Program Correctness
● Program correctness:
● Specification and verification of what a given
program does
● Must satisfy two classes of properties: safety
and liveness.

● Safety property:
● assert that nothing ‘bad’ will ever happen
during an execution (that is, that the program
will never enter a ‘bad’ state)

● Liveness property:
● assert that something ‘good’ will eventually
happen during execution.
● concerned with making progress in a program
Program Correctness
● Single lane bridge problem
Program Correctness
● Safety property: specify a property to ensure
that cars do not collide (e.g. impose one-way
rule)
Program Correctness
● Liveness property: does every car eventually
get an opportunity to cross the bridge (i.e.
make progress)?
 10.2
Mutual Exclusion
Mutual Exclusion (mutex)
● The problem of making sure that one
thread at a time can execute a particular
block of code (critical section)

● Understanding how to implement mutual

exclusion is essential for understanding
concurrent computation

● Mutex is a coordination problem

Mutual Exclusion (mutex)
● How to implement mutex in software?
● Use some “lock” library

● Imagine there is no lock library, and you

have to invent it

● Let’s go through a couple of scenarios of

how we could create one
 Mutual Exclusion: A Story
● Alice and Bob are
neighbours, share a yard
● Alice has a cat
A B
● Bob has a dog
● Cats and dogs don’t get
along
● How do Alice and Bob
share the yard?

We have to invent a protocol for mutual

exclusive access to the shared resource (yard)
Formalizing the problem
● Mutual exclusion
● Both pets should never be in the yard at the
same time
● This is a safety property – makes sure that
nothing bad happens

● No deadlock
● If only one wants in, it gets in
● If both want in, only one gets in
● This is a liveness property – makes sure
that something good happens eventually
 A B
Protocol 1: Viewing

● Idea:
● Look at the yard to see if it is empty

● Problem:
● Trees obscure the view
● Alice and Bob might look at (almost) the same
time, and both conclude that the yard is empty.

● Interpretation:
● Looking at the yard and releasing a pet are
distinct atomic steps.
● Explicit communication required for
coordination
Protocol 2: Cellphone Protocol
● Idea:
● Bob calls Alice (or vice-versa) to ask to release
the pet

● Problem:
● Alice may be taking a shower, shopping for pet
food, or her cellphone may be off

● Interpretation:
● Transient communication (like talking) isn’t ideal
● Recipient might not be listening, or there at all
● Communication should be persistent (like sending
mail)
Protocol 3: Can Protocol

● Idea:
● Put a can on Alice’s windowsill, with a string to Bob’s
house (and vice-versa)
● When Bob wants to release the dog, pulls string
knocking over Alice’s can (“sends a message”)
● Bob releases the dog if Alice’s can is down and his
can is up. And vice-versa.
Protocol 3: Can Protocol

● Problem:
● Bob needs Alice to reset her can after the dog has left
the yard. And vice-versa.
● What if Alice goes away on holiday?

● Interpretation:
● Interrupts aren’t ideal for solving mutual exclusion.
Alice and Bob better control their own signals.
Protocol 4: Flag Protocol

A B
Flag Protocol
Alice’s Protocol:
● Raise flag
● Wait until Bob’s flag is down
● Release pet Question:
● Lower flag when pet returns What would happen if
both Alice and Bob
Bob’s Protocol: raise their flags at the
● Raise flag same time?
● Wait until Alice’s flag is down
● Release pet
● Lower flag when pet returns
Flag Protocol Question:
Why isn’t it a good
idea to let both Alice
Alice’s Protocol: and Bob be “polite”?
● Raise flag
● Wait until Bob’s flag is down No, no…
After you!
● Release pet after you!
● Lower flag when pet returns

Bob’s Protocol:
● Raise flag
● Wait until Alice’s flag is down
● Release pet
● Lower flag when pet returns
A deadlock could occur
Flag Protocol
Alice’s Protocol:
● Raise flag
● Wait until Bob’s flag is down
● Release pet
● Lower flag when pet returns

Bob’s Protocol (2nd try):

● Raise flag
Bob defers
● While Alice’s flag is up:
● Lower flag
to Alice
● Wait until Alice’s flag is down
● Raise flag
● Release pet
● Lower flag when pet returns
The Flag Principle
● Raise the flag
● Look at other’s flag
● Flag Principle:
● If each raises and looks, then last to look
must see both flags up

Many coordination protocols use flag raising and

the flag principle to guarantee that threads notice
each other.
Does the flag protocol work?
● Mutual exclusion?
● YES
● Pets are not in the yard at the same time

● Deadlock-freedom?
● YES
● If both pets want to use the yard, Bob
defers to Alice
Does the flag protocol work?
● Starvation-freedom?
If a pet wants to enter the yard, will it
eventually succeed?
● NO.
● Whenever Alice and Bob are in conflict, Bob
defers to Alice, thus it is possible that Alice’s
pet uses the yard over and over and Bob’s
pet doesn’t get a turn
Waiting
● If Alice raises her flag and suddenly
becomes ill, Bob’s pet cannot use the
yard until Alice returns

● Bob must wait for Alice to lower her flag

Remarks
● Flag protocol is unfair
● Bob’s pet might never get in (starvation)

● Flag protocol uses waiting

● If Bob is eaten by his pet, Alice’s pet might
never get in
● Problematic in terms of performance
Moral of the Story
● Mutual Exclusion cannot be solved by
● transient communication (cell phones)
● interrupts (cans)

● It can be solved by
● one-bit shared variables that can be read or
written (flags)