ConcIT
Concurrency 2010
Hand-in #1
José Antonio Esparza 20097706
jaesparza@gmail.com
Torben Grøn Helligsø 20097659
thel@gmx.com
Anders Nielsen 20090089
anders2209@gmail.com
1. What is a monitor (following the terminology used in this course)?
According to the terminology used in this course, a monitor is a shared
resource that can be accessed only by one thread at a time. The threads
represent the active elements that handle the monitors, which are passive
elements that respond to thread initiated actions.
The monitor term in java refers to a different concept, specifically to the
means that provide the object locks.
2. What is condition synchronization, and how does it appear in FSP and
Java?
The case in which a certain condition is required to be satisfied before a
thread can execute a critical section protected by e.g a monitor is called
condition synchronization. The thread will give up its processor time until the
condition is met.
In FSP, the condition synchronization is modelled with a guard using the when
keyword (Car Park example):
SPACES[spaces:0..CAPACITY] =
(when(spaces>0) arrive ->SPACES[spaces-1]
|when(spaces<CAPACITY) depart -> SPACES[spaces+1]).
In Java, a fool-proof design
synchronization is given by:
pattern
implementing
the
condition
Side 1 af 4
ConcIT
public synchronized void action()
throws InterrruptedException
{
while(!cond)
wait();
// critical section goes here
notifyAll();
}
In some cases, the call to notifyAll() may be replaced by notify(), which wakes
up a single random thread in the synchronization object's wait set (as
opposed to waking up every thread in the wait set. Waking up only a single
thread is more efficient.
3. Consider the Dining Philosophers example. For each of the four
deadlock conditions, give an example of how to break the condition
such that the philosophers cannot deadlock.
a) Serially reusable resources: Removed the aspect of shared resources by
giving them a set of forks each.
b) Incremental acquisition : Have the philosophers pick up both the left and
right fork in one go, instead of first picking up the right, then the left.
c) No preemption: Allow the stronger philosophers to break etiquette by
simply grabbing the forks they need, whenever they feel like it.
d) Wait-for cycle: Break cyclic dependence by introducing an outside party
that allows at most four philosophers to initiate sitting down. This way it is not
possible for all four philosophers to be waiting for a free left fork, at the same
time
Another way to break the wait-for cycle is to introduce some kind of
asymmetry as demonstrated by Lehman and Rabin (1981). One solution is to
have the even-numbered philosophers pick up the left fork first and then the
right. The odd numbered should continue picking up the right fork first.
4. Explain (informally) the cause of the deadlock in the first version of
Bounded Buffer (see [M&K] Ch.5) and the fix in the second version.
When using a bounded buffer there are two things in need of mutual
exclusion: The data in need of buffering and the data that lets the producer
and consumer know where to “go” next. These two different kinds of
information has no bearing on each other. They are said to be dataindependent
Yet mutual exclusion to semaphores full and empty is obtained prematurely
Side 2 af 4
ConcIT
by the consumer, due to the nesting of semaphores in the bounded buffer.
Due to this nesting of monitors, the buffer is deadlocked in the event that a
consumer (thread) looks in the buffer before something has been put in, since
the consumer thread waits until something has been put in, while maintaining
exclusive access to the buffer. This prevents the producer from ever putting
data in the buffer and this is known as the nested monitor problem.
The solution is to move semaphore actions from within the monitor (the
synchronized block), thereby avoiding the problem of the consumer thread
holding on to the buffer lock, while waiting.
5. Why must an FSP safety property satisfy the two requirements
mentioned on slide 48?
Requirement 1: composing a safety property process with the system
processes does not constrain their operation, unless the desired property is
violated.
The safety property must accept as valid a trace or set of traces that
are already present in the system, and can be detected as possible
execution results of the model.
Requirement 2: must be deterministic.
Safety properties must be deterministic because it should be possible
to determine or assert if the trace or traces contained in the defined
property are accepted or not.
6. Explain (informally) why the progress analysis algorithm (slide 61)
works.
The progress analysis algorithm enables to check the progress property of a
LTS. The progress property holds that at any stage of execution, one of the
actions in the progress set will eventually occur [1].
One of the key steps in the progress analysis algorithm is to identify the
terminal states on the algorithm graph. This implies that the algorithm is
locating the strongly connected components, which have got no path to any
nodes outside the defined set of states. The reason why this algorithm works
is due to this last step. Each action out of the terminal set will never be
executed infinitely often in all executions of the system. If an action is not
contained in any terminal set present at the system and a progress property is
defined upon that action, that property is violated.
Side 3 af 4
ConcIT
7. What effect do action priorities (the << and >> operators in FSP) have
on the labeled transition systems being constructed by LTSA?
Effect of the High Priority Operator (<<): When a process R offering a choice
of carrying out either action a, b or action c, is composed with Process D in
which action b is specified to be of high priority, all the transitions labeled a
and c in the resulting transition system are removed.
Effect of the low Priority Operator (>>): When a process T offering a choice of
carrying out either action a, b c, is composed with Process U in which action
b is specified to be of low priority, all the transitions labeled b in the resulting
transition system are removed.
References:
1. Maggee, Jeff and Kramer Jeff. “Concurrency: State models & Java
programming”. Second edition. Wiley international 2006.
Side 4 af 4