Book Chapter 7

1
Concurrency
Safety Liveness Properties
Claus Brabrand brabrand_at_daimi.au.dk University of
Aarhus
2
Repetition

• Deadlock

3
Concepts, Models, and Practice

• Concepts
• deadlock (no further progress)
• 4x necessary AND sufficient conditions
• Models
• no eligible actions (analysis gives shortest path
  trace)
• Practice
• blocked threads

Aim - deadlock avoidance Break at least one of
the deadlock conditions.
4
Deadlock 4 Necessary AND Sufficient Conditions
1. Mutual exclusion cond. (aka. Serially
reusable resources) the processes involved
share resources which they use under mutual
exclusion. 2. Hold-and-wait condition (aka.
Incremental acquisition) processes hold
on to resources already allocated to them while
waiting to acquire additional resources. 3.
No pre-emption condition once acquired by a
process, resources cannot be pre-empted
(forcibly withdrawn) but are only released
voluntarily. 4. Circular-wait condition (aka.
Wait-for cycle) a circular chain (or
cycle) of processes exists such that each process
holds a resource which its successor in the
cycle is waiting to acquire.
5
Dining Philosophers (Concepts, Models and
Practice)

• Concepts

• Models

• Practice

6
Repetition Invariants

• Invariant (valid predicate)
• (The principle of mathematical) induction
• Proof (induction in iterations)
• Base case
• True first iteration
• Induction step
• True (i1)th iteration,(assuming IHTrue ith
  iteration)

P(x,y) ? xgt2 ? x y 10
?
?
?n?N P(n)
P(0)
P(i) ? P(i1)
int fac(int x) // x 0 int result 1
int rest x while (rest ! 0) //
INV x! result rest! result rest
rest-- // INV x! result
return result
7
Chapter 7
Safety Liveness Properties
8
Safety Liveness Properties
Concepts Properties true for every possible
execution Safety nothing bad ever
happens Liveness something good
eventually happens Models Safety
no reachable ERROR/STOP state Progress an
action is eventually executed (fair
choice and action priority) Practice
Threads and monitors
Aim property satisfaction.
9
Agenda

• Part I/III
• Safety
• Part II/III
• Liveness
• Part III/III
• Example Reader/Writer

10
Safety

• Part I/III

11
7.1 Safety
A safety property asserts that nothing bad
happens.

• STOP or deadlocked state (no outgoing
  transitions)
• ERROR process (-1) to detect erroneous behaviour

RESOURCE (acquire-gtACQUIRED), ACQUIRED
(release-gtRESOURCE acquire-gtERROR).
Trace to ERROR acquire acquire

• Analysis using LTSA
• (shortest trace)

12
STOP vs. ERROR
Trace

• STOP
• ERROR

p q p stop q q ?
P (p-gtP stop-gtSTOP). Q (q-gtQ). SYSv1
(P Q).
LTSAgt No deadlocks detected
Trace
p q p error
P (p-gtP error-gtERROR). Q (q-gtQ). SYSv2
(P Q).
SYSTEM DEADLOCKED
LTSAgt Trace to deadlock error
13
Safety - Property Specification

• ERROR conditions state what is not required (
  exceptions).
• In complex systems, it is usually better to
  specify safety properties by stating directly
  what is required.

property SAFE_RESOURCE (acquire -gt
release -gt SAFE_RESOURCE).
RESOURCE (acquire -gt (release -gt
RESOURCE acquire -gt ERROR) release -gt
ERROR).
14
Safety Properties
Property that it is polite to knock before
entering a room.
Traces knock-gtenter ? enter ? knock-gtknock
?
property POLITE (knock -gt enter -gt POLITE).
Note In all states, all the actions in the
alphabet of a property are eligible choices.
15
Safety Properties
Safety property P defines a deterministic process
that asserts that any trace including actions in
the alphabet of P, is accepted by P.
Thus, if S is composed with P, then traces of
actions in the alphabet ?(S) ? ?(P) must also be
valid traces of P, otherwise ERROR is reachable.
Transparency of safety properties Since all
actions in the alphabet of a property are
eligible choices gt composition with S does not
affect its correct behavior. However, if a bad
behavior can occur (violating the safety
property), then ERROR is reachable.
and hence detectable through verification (using
LTSA)!
16
Safety Properties

• How can we specify that some action, disaster,
  never occurs?

NO_DISASTER (disaster-gtERROR).
...or...
property CALM STOP disaster.
A safety property must be specified so as to
include all the acceptable, valid behaviors in
its alphabet.
17
Models vs. Properties Implementation vs.
Specification

• The model is for the implementation
• The property is for the specification
• The implementation is required to meet the
  specification
• Often
• Operational model (M) implementation
• Declarative formula (?) specification
• However, in FSP(/LTSA) both models and properties
  are described using the same language (namely
  FSP) ?
• Operational model FSP process
• Operational property FSP property (process)
• They will be similar (because they are using the
  same language), but they do not represent the
  same thing!

?t,t acquire(t) ? acquire(t) ? tltt gt ?t
tlttltt ? release(t)
property P (acquire -gt release -gt P).
18
Safety - Mutual Exclusion
LOOP (mutex.down -gt enter-gtc-gtexit -gt
mutex.up -gt LOOP). SEMADEMO (p1..3LOOP
p1..3mutexSEMAPHORE(1)).
How do we check that this does indeed ensure
mutual exclusion in the critical section (c)?
property MUTEX (pi1..3.enter -gt pi.exit
-gt MUTEX). CHECK (SEMADEMO MUTEX).
Check safety using LTSA!
What if SEMAPHORE(2)?
?t,t enter(t) ? enter(t) ? tltt gt ?t
tlttltt ? exit(t)
19
7.2 Example Single Lane Bridge Problem
A bridge over a river is only wide enough to
permit a single lane of traffic. Consequently,
cars can only move concurrently if they are
moving in the same direction. A safety violation
occurs if two cars moving in different directions
enter the bridge at the same time.
20
Single Lane Bridge - Model
Using an appropriate level of abstraction!

• Events or actions of interest?
• enter and exit
• Identify processes?
• car and bridge
• Identify properties?
• oneway

Structure diagram
Verbs
Nouns
Adjectives
21
Single Lane Bridge - CARS Model
const N 3 // cars (of each color) range
ID 1..N // car identities CAR
(enter-gtexit-gtCAR). // car process N_CARS
(IDCAR). // N cars
22
Single Lane Bridge - CONVOY Model
NOPASS_ENTER SEQ1, // preserves entry
order SEQiID (i.enter -gt
SEQiN1). NOPASS_EXIT SEQ1, //
preserves exit order SEQiID (i.exit -gt
SEQiN1). CONVOY (IDCAR
NOPASS_ENTER NOPASS_EXIT).
Permits
1.enter 1.exit 2.enter 2.exit 1.enter
2.enter 1.exit 2.exit
1.enter 2.enter 2.exit 1.exit
but not
i.e. no overtaking
23
Single Lane Bridge - BRIDGE Model
Cars can move concurrently on bridge, but only in
thesame direction (gt controller)!
How ideas?
The bridge maintains a count of blue and red cars
on it. Red cars are only allowed to enter when
the blue count is 0 (and vice-versa).
range T 0..N
BRIDGE00, // initly empty
bridge BRIDGEnrTnbT // nr red nb
blue (when (nb0) redID.enter -gt
BRIDGEnr1nb redID.exit -gt
BRIDGEnr-1nb when (nr0) blueID.enter-gt
BRIDGEnrnb1 blueID.exit -gt
BRIDGEnrnb-1 ).
BRIDGE
24
Single Lane Bridge - BRIDGE Model
Warning - BRIDGE.-1.0 defined to be ERROR Warning
- BRIDGE.0.-1 defined to be ERROR Warning -
BRIDGE.-1.1 defined to be ERROR Warning -
BRIDGE.-1.2 defined to be ERROR Warning -
BRIDGE.-1.3 defined to be ERROR Warning -
BRIDGE.0.4 defined to be ERROR Warning -
BRIDGE.1.-1 defined to be ERROR Warning -
BRIDGE.2.-1 defined to be ERROR Warning -
BRIDGE.4.0 defined to be ERROR Warning -
BRIDGE.3.-1 defined to be ERROR Compiled BRIDGE
Sloppy controller Even when 0, exit actions
permit the car counts to be decremented (i.e.
unguarded exit actions)
Recall that LTSA maps such undefined states to
ERROR.
No, because cars are well-behaved (i.e. they
never exit before enter)
Is it a problem?
25
Single Lane Bridge - Safety Property ONEWAY
We now specify a safety property to check that
cars do not collide!
property ONEWAY EMPTY, EMPTY
(redID.enter -gt ONLY_RED1
blueID.enter -gt ONLY_BLUE1), ONLY_REDiID
( redID.enter -gt REDi1
when (i1) redID.exit -gt EMPTY
when (igt1) redID.exit -gt
REDi-1), ONLY_BLUEjID (
blueID.enter -gt BLUEj1
when (j1) blueID.exit -gt EMPTY
when (jgt1) blueID.exit -gt BLUEj-1).
When the bridge is empty, either a red or a blue
car may enter.
While red cars are on the bridge only
red cars can enter similarly for blue cars.
26
Single Lane Bridge - Model Analysis
A red and a blue convoy of N cars for each
direction
CARS (redCONVOY blueCONVOY).
SingleLaneBridge (CARSBRIDGEONEWAY).
Is the safety property ONEWAY violated?
No deadlocks/errors
And without the BRIDGE (controller)
SingleLaneBridge (CARSBRIDGEONEWAY).
Trace to property violation in
ONEWAY red.1.enter blue.1.enter
Is the safety property ONEWAY violated?
27
Model / Property Implementation / Specification?
Model ( implementation)
BRIDGE BRIDGE00, // initly empty
bridge BRIDGEnrTnbT // nr red nb
blue (when (nb0) redID.enter -gt
BRIDGEnr1nb redID.exit
-gt BRIDGEnr-1nb when (nr0)
blueID.enter -gt BRIDGEnrnb1
blueID.exit -gt BRIDGEnrnb-1).
Property ( specification)
property ONEWAY EMPTY, EMPTY
(redID.enter -gt RED1
blueID.enter -gt BLUE1), REDiID (
redID.enter -gt REDi1 when
(i1) redID.exit -gt EMPTY when
(igt1) redID.exit -gt REDi-1), BLUEjID
( blueID.enter -gt BLUEj1
when (j1) blueID.exit -gt EMPTY
when (jgt1) blueID.exit -gt BLUEj-1).
28
Model / Property Implementation / Specification?

• Controller model ( implementation)
• Behavior (which actions are permitted)
• Property observer ( specification)
• All legal traces over (often smaller) alphabet
• May be many properties checking different aspects
  of an impl.
• Our controller meets its specification (i.e. no
  errors/deadlocks).
• although sloppy (e.g. unguarded exits)
• You cannot cheat here and use the controller as
  your specification (by prefixing it with
  property)
• it allows wrong behaviors (e.g. unguarded
  exits)
• since it assumes well-behaved cars (that dont
  exit before enter)
• The property specifies(/asserts) good behavior
  for the whole system ( controllercars)

29
Single Lane Bridge - Implementation in Java (UML)
CAR (active gt thread) BRIDGE (passive gt
monitor)
BridgeCanvas enforces no overtaking (
NOPASS_ENTER).
30
Single Lane Bridge - BridgeCanvas
An instance of BridgeCanvas class is created by
the SingleLaneBridge applet.
class BridgeCanvas extends Canvas public
void init(int ncars) // set cars
public boolean moveRed(int i) throws
IntExc // moves red car i a step (if
possible) // returns true if on bridge
public boolean moveBlue(int i) throws
IntExc // moves blue car i a step (if
possible) // returns true if on bridge
Each Car object is passed a reference to the
BridgeCanvas.
31
Single Lane Bridge - RedCar
class RedCar implements Runnable Bridge
control BridgeCanvas display int id
RedCar(Bridge b, BridgeCanvas d, int i)
control b display d id i
public void run() try
while (true) while
(!display.moveRed(id)) // not on br.
control.redEnter() // req access to br.
while (display.moveRed(id)) //
move on br control.redExit() //
release access to br.
catch (InterruptedException _)
Similarly for the BlueCar...
32
Single Lane Bridge - Class Bridge
class Bridge synchronized void redEnter()
throws IntExc synchronized void
redExit() synchronized void blueEnter()
throws IntExc synchronized void
blueExit()
Class Bridge provides a null implementation of
the access methods i.e. no constraints on the
access to the bridge.
Result ?
33
Single Lane Bridge
8 people dead!
34
Single Lane Bridge - SafeBridge
BRIDGEnrTnbT // nr red nb blue
(when (nb0) redID.enter -gt BRIDGEnr1nb
redID.exit -gt BRIDGEnr-1nb
class SafeBridge extends Bridge protected
int nred 0 // red cars on br. protected
int nblue 0 // blue cars on br. //
monitor invariant nred0 ? nblue0 ? //
?(nredgt0 ? nbluegt0)
synchronized void redEnter() throws IntExc
while (!(nblue0)) wait()
nred synchronized void redExit()
--nred notifyAll()
35
Single Lane Bridge - SafeBridge
synchronized void blueEnter() throws IntExc
while (!(nred0)) wait()
nblue synchronized void blueExit()
--nblue if (nblue0) notifyAll()
To avoid (potentially) unnecessary thread
switches, we use conditional notification to
wake up waiting threads only when the number of
cars on the bridge is zero (i.e., when the last
car leaves the bridge).
But does every car eventually get an opportunity
to cross the bridge...? This is a liveness
property.
36
Single Lane Bridge
To ensure safety, the safe check box must be
chosen in order to select the SafeBridge
implementation.
37
Liveness

• Part II/III

38
7.3 Liveness
A safety property asserts that nothing bad
happens. A liveness property asserts that
something good eventually happens.
Does every car eventually get an opportunity to
cross the bridge (i.e., make progress)?
A progress property asserts that it is always
the case that an action is eventually
executed. Progress is the opposite of starvation
( the name given to a concurrent programming
situation in which an action is never executed).
39
Progress Properties - Fair Choice
Fair Choice If a choice over a set of
transitions is executed infinitely often, then
every transition in the set will be executed
infinitely often.
COIN (toss-gtheads-gtCOIN
toss-gttails-gtCOIN).
How about if we chose toss(1) 100.000x
then toss(2) 1x then toss(1) 100.000x
then toss(2) 1x then Fair?
Lets assume Fair Choice...
40
Progress Properties
progress P a1, a2, , an
This defines a progress property, P, which
asserts that in an infinite execution, at least
one of the actions a1, a2, , an will be
executed infinitely often.
COIN (toss-gtheads-gtCOIN toss-gttails-gtCOIN).
?
progress HEADS heads ? progress TAILS
tails ?
?
LTSA check progress
No progress violations detected
41
Progress Properties
Suppose that there were two possible coins that
could be picked up a regular coin and a trick
coin
TWOCOIN (pick-gtCOIN pick-gtTRICK), COIN
(toss-gtheads-gtCOIN toss-gttails-gtCOIN), TRICK
(toss-gtheads-gtTRICK).
progress HEADS heads ? progress TAILS
tails ?
?
?
42
Progress Properties
progress HEADS heads progress TAILS tails
Progress violation TAILS Path to terminal set of
states pick Actions in terminal set toss,
heads
?
progress P heads,tails ?
43
Topological Sorting

• Given oriented graph G
• TopSort(G) acyclic graph where
  nodes are collections of G nodes
  called strongly connected
  components
• TopSort can be implemented very
  efficiently (in time O(G)).

ltlt Examples on blackboard gtgt
44
Progress Analysis
A terminal set of states is one in which every
state is reachable from every other state in the
set via one or more transitions, and there is no
transition from within the set to any state
outside the set.
Terminal sets for TWOCOIN ? 1,2 and ?
3,4,5
Given fair choice, each terminal set represents
an execution in which each action used in a
transition in the set is executed infinitely
often. Since there is no transition out of a
terminal set, any action that is not used in the
set cannot occur infinitely often in all
executions of the system - and hence represents a
potential progress violation!
45
Progress Analysis
A progress property is violated if analysis finds
a terminal set of states in which none of the
progress set actions appear.
progress TAILS tails in 1,2 ?
Default progress for every action in the
alphabet, that action will be executed infinitely
often. This is equivalent to specifying a
separate progress property for every action.
46
Progress Analysis Default Progress
Default progress
Progress violation for actions pick Path
to terminal set of states pick Actions in
terminal set toss, heads, tails
Progress violation for actions pick,
tails Path to terminal set of states pick Actio
ns in terminal set toss, heads
Note default holds gt every other progress
property holds (i.e., every action is executed
infinitely often and the system consists of a
single terminal set of states).
47
Progress Return of the Single Lane Bridge
The implementation exhibitsprogress violations
progress BLUECROSS blueID.enter progress
REDCROSS redID.enter
However, the model doesnt
No progress violations detected.
In fact, no violations of even default progress!
Fair choice means that eventually every possible
execution occurs, including those in which cars
do not starve. To detect progress problems we
must superimpose some scheduling policy for
actions, which models the situation in which the
bridge is congested.
48
Progress - Action Priority
Action priority expressions describe scheduling
properties
C (PQ)ltlta1,,an specifies a composition
in which the actions a1,..,an have higher
priority than any other action in the alphabet of
PQ including the silent action tau. In any
choice in this system which has one or more of
the actions a1,..,an labeling a transition, the
transitions labeled with lower priority actions
are discarded.
High Priority (ltlt)
C (PQ)gtgta1,,an specifies a composition
in which the actions a1,..,an have lower priority
than any other action in the alphabet of PQ
including the silent action tau. In any choice
in this system which has one or more transitions
not labeled by a1,..,an, the transitions labeled
by a1,..,an are discarded.
Low Priority (gtgt)
49
Progress - Action Priority Example
NORMAL (work-gtplay-gtNORMAL
sleep-gtplay-gtNORMAL).
Action priority simplifies the resulting LTS by
discarding lower priority actions from choices.
HIGH (NORMAL)ltltwork.
LOW (NORMAL)gtgtwork.
50
7.4 Congested Single Lane Bridge
progress BLUECROSS blueID.enter progress
REDCROSS redID.enter
BLUECROSS - eventually one of the blue cars will
be able to enter REDCROSS - eventually one of the
red cars will be able to enter
Congestion using action priority? Could give red
cars priority over blue (or vice versa) ?
In practice neither has priority over the
other. Instead we merely encourage congestion
by lowering the priority of the exit actions of
both cars from the bridge.
CongestedBridge (SingleLaneBridge) gtgtred
ID.exit,blueID.exit.
51
Congested Single Lane Bridge Model
Progress violation BLUECROSS Path to terminal
set of states red.1.enter red.2.enter Actions
in terminal set red.1.enter, red.1.exit,
red.2.enter, red.2.exit, red.3.enter,
red.3.exit Progress violation REDCROSS Path to
terminal set of states blue.1.enter blue.2.ente
r Actions in terminal set blue.1.enter,
blue.1.exit, blue.2.enter, blue.2.exit,
blue.3.enter, blue.3.exit
This corresponds with the observation that, with
more than one car, it is possible that whichever
color car enters the bridge first will
continuously occupy the bridge preventing the
other color from ever crossing.
52
Congested Single Lane Bridge Model
CongestedBridge (SingleLaneBridge) gtgtred
ID.exit,blueID.exit.
Will the results be the same if we model
congestion by giving car entry to the bridge high
priority? Can congestion occur if there is only
one car moving in each direction?
53
Progress - Revised Single Lane Bridge Model
The bridge needs to know whether or not cars are
waiting to cross. Modify CAR
CAR (request -gt enter -gt exit -gt CAR).
The car signals bridge that it has arrived
wants to enter.
Modify BRIDGE Red cars are only allowed to enter
the bridge if there are no blue cars on the
bridge and there are no blue cars waiting to
enter the bridge. ...and vice-versa for blue
cars.
54
Progress - Revised Single Lane Bridge Model
// nr red cars on br. wr red cars waiting
to enter // nb blue cars on br. wb blue cars
waiting to enter BRIDGE BRIDGE0000,
BRIDGEnrTnbTwrTwbT (
redID.request -gt BRIDGEnrnbwr1wb
when (nb0 wb0)
redID.enter -gt BRIDGEnr1nbwr-1wb
redID.exit -gt BRIDGEnr-1nbwrwb
blueID.request -gt
BRIDGEnrnbwrwb1 when (nr0
wr0) blueID.enter -gt
BRIDGEnrnb1wrwb-1 blueID.exit
-gt BRIDGEnrnb-1wrwb ).
OK now?
55
Progress - Analysis of Revised Single Lane Bridge
Model
The trace is the scenario in which there are cars
waiting at both ends, and consequently, the
bridge does not allow either red or blue cars to
enter. Solution?
Trace to DEADLOCK red.1.request red.2.request
red.3.request blue.1.request blue.2.request blu
e.3.request
Introduce some asymmetry in the problem (cf.
Dining philosophers).
This takes the form of a boolean variable (bt)
which breaks the deadlock by indicating whether
it is the turn of blue cars or red cars to enter
the bridge. Arbitrarily initialize bt to true
initially giving blue initial precedence.
56
Progress - 2nd Revision of Single Lane Bridge
Model
const True 1 const False 0 range B
False..True // bt true blue turn
// false red turn BRIDGE
BRIDGE0000True, BRIDGEnrTnbTwr
TwbTbtB ( redID.request -gt
BRIDGEnrnbwr1wbbt when (nb0
(wb0!bt)) redID.enter -gt
BRIDGEnr1nbwr-1wbbt redID.exit
-gt BRIDGEnr-1nbwrwbTrue
blueID.request -gt BRIDGEnrnbwrwb1b
t when (nr0 (wr0bt))
blueID.enter -gt BRIDGEnrnb1wrwb-1bt
blueID.exit -gt BRIDGEnrnb-1wrwb
False ).
Analysis ?
No progress violations detected. ?
57
Revised Single Lane Bridge Implementation -
FairBridge
BRIDGEnrTnbTwrTwbTbtB (
redID.request -gt BRIDGEnrnbwr1wbbt
when (nb0 (wb0!bt))
redID.enter -gt BRIDGEnr1nbwr-1wbbt
class FairBridge extends Bridge protected
int nred, nblue, wblue, wred protected
boolean blueturn true synchronized void
request() wred
synchronized void redEnter() throws IntExc
while (!(nblue0 (waitblue0
!blueturn))) wait() --wred
nred
58
Revised Single Lane Bridge Implementation -
FairBridge
BRIDGEnrTnbTwrTwbTbtB (
redID.request -gt BRIDGEnrnbwr1wbbt
when (nb0 (wb0!bt))
redID.enter -gt BRIDGEnr1nbwr-1wbbt
redID.exit -gt BRIDGEnr-1nbwrwb
True
class FairBridge extends Bridge
synchronized void redExit() --nred
blueturn true if (nred0)
notifyAll()
59
Revised single lane bridge implementation -
FairBridge
Use FairBridge monitor
Note we do not need to introduce a new request
monitor method. The existing enter methods can be
modified to increment a wait count before testing
whether or not the caller can access the
bridge... see next slide
60
Implementation short-cut Implicit Request
synchronized void request()
wred synchronized void redEnter() throws
IntExc while (!(nblue0 (waitblue0
!blueturn))) wait() --wred nred
...is equivalent to...
synchronized void redEnter() throws IntExc
// request wred // enter while
(!(nblue0 (waitblue0 !blueturn)))
wait() --wred nred
61
Example Readers/Writers

• Part III/III

62
7.5 Readers and Writers
Light blue indicates database access.
A shared database is accessed by two kinds of
processes. Readers execute transactions that
examine the database while Writers both examine
and update the database. A Writer must have
exclusive access to the database any number of
Readers may concurrently access it.
63
Readers and Writers Model

• Events or actions of interest?
• acquireRead, releaseRead, acquireWrite,
  releaseWrite
• Identify processes.
• Readers, Writers the RW_Lock
• Identify properties.
• RW_Safe
• RW_Progress
• Structure diagram

64
Readers/Writers Model - READER WRITER
READER (acquireRead -gt
examine -gt releaseRead
-gt READER) \
examine. WRITER (acquireWrite -gt
modify -gt
releaseWrite -gt
WRITER) \ modify.
Action hiding is used as actions examine and
modify are not relevant for access
synchronization.
65
Readers/Writers Model - RW_LOCK
const False 0 const True 1 range Bool
False..True const Nread 2 // readers const
Nwrite 2 // writers RW_LOCK
RW0False, RWreaders0..NreadwritingBool
( when (!writing) acquireRead -gt
RWreaders1writing releaseRead
-gt RWreaders-1writing when
(readers0 !writing)
acquireWrite -gt RWreadersTrue
releaseWrite -gt
RWreadersFalse ).
The lock maintains a count of the number of
readers, and a boolean for the writers.
66
Readers/Writers Model - Safety
property SAFE_RW NO_ONE, NO_ONE (acquireRead
-gt READING1 acquireWrite
-gt WRITING), READINGi1..Nread
(acquireRead -gt READINGi1
when (igt1) releaseRead -gt READINGi-1
when (i1) releaseRead -gt NO_ONE
), WRITING (releaseWrite -gt NO_ONE).
READWRITELOCK (RW_LOCK SAFE_RW).
We can check that RW_LOCK satisfies the safety
property
67
Readers/Writers Model
We can now compose the RW_LOCK with READER and
WRITER processes according to our structure
No deadlocks/errors. ?
68
Readers/Writers Model - Progress
progress WRITE writer1..Nwrite.acquireWrite
progress READ reader1..Nread.acquireRead
WRITE - eventually one of the writers will
acquireWrite READ - eventually one of the readers
will acquireRead
No progress violations detected. ?
69
Readers/Writers Model - Progress
Progress violation WRITE Path to terminal set of
states reader.1.acquireRead Actions in terminal
set reader.1.acquireRead, reader.1.releaseRead,
reader.2.acquireRead, reader.2.releaseRead
Writer starvation The number of readers never
drops to zero.
70
Readers/Writers Implementation - Monitor Interface
We concentrate on the monitor implementation
interface ReadWrite void acquireRead()
throws IntExc void releaseRead() void
acquireWrite() throws IntExc void
releaseWrite()
We define an interface that identifies the
monitor methods that must be implemented, and
develop a number of alternative implementations
of this interface. Firstly, the safe
READWRITELOCK.
71
Readers/Writers Implementation - ReadWriteSafe
class ReadWriteSafe implements ReadWrite
protected int readers 0 protected boolean
writing false synchronized void
acquireRead() throws IntExc while
(writing) wait() readers
synchronized void releaseRead()
--readers if(readers0) notify()

Unblock a single writer when no more readers.
72
Readers/Writers Implementation - ReadWriteSafe
synchronized void acquireWrite() throws IntExc
while (readersgt0 writing) wait()
writing true synchronized void
releaseWrite() writing false
notifyAll()
Unblock all readers
However, this monitor implementation suffers from
the WRITE progress problem possible writer
starvation if the number of readers never drops
to zero.
73
Readers/Writers - Writer Priority
Strategy Block readers if there is a writer
waiting.
requestWrite -gt
74
Readers/Writers Model - Writer Priority
RW_LOCK RW0False0, RWreaders0..Nreadwr
itingBoolwaitingW0..Nwrite ( when
(!writing waitingW0)
acquireRead -gt RWreaders1writingwaitingW
releaseRead -gt RWreaders-1writingwa
itingW when (readers0 !writing)
acquireWrite -gt RWreadersTruewaitingW-1
releaseWrite -gt RWreadersFalsewait
ingW requestWrite -gt
RWreaderswritingwaitingW1 ).
RW_P R_W gtgt.release. // simulate
Intensive usage
75
Readers/Writers Model - Writer Priority
property RW_SAFE
No deadlocks/errors
progress READ and WRITE
Progress violation READ Path to terminal set of
states writer.1.requestWrite writer.2.requestWr
ite Actions in terminal set writer.1.requestWrit
e, writer.1.acquireWrite, writer.1.releaseWrite,
writer.2.requestWrite, writer.2.acquireWrite,
writer.2.releaseWrite
Reader starvation if always a writer waiting.
In practice this may be satisfactory as is
usually more read access than write, and readers
generally want the most up to date information.
76
Readers/Writers Implementation - ReadWritePriority
class ReadWritePriority implements ReadWrite
protected int readers 0 protected boolean
writing false protected int waitingW 0
// waiting writers synchronized void
acquireRead() throws IntExc while
(writing waitingWgt0) wait()
readers synchronized void
releaseRead() --readers if
(readers0) notify()
77
Readers/Writers Implementation - ReadWritePriority
synchronized void acquireWrite() throws IntExc
// request write waitingW //
acquire write while (readersgt0 writing)
wait() --waitingW writing
true synchronized void releaseWrite()
writing false notifyAll()
Both READ and WRITE progress properties can be
satisfied by introducing a turn variable as in
the Single Lane Bridge.
78
Summary

• Concepts
• properties true for every possible execution
• safety nothing bad ever happens
• liveness something good eventually happens
• Models
• safety no reachable ERROR/STOP state
• compose safety properties at appropriate stages
• progress an action is eventually executed
• fair choice and action priority
• apply progress check on the final target
  system model
• Practice
• threads and monitors

Aim property satisfaction