Download pdf - Concurrent Programing

8/4/2019 Concurrent Programing

1/74

Concurrent Programming

Eitan Farchi


2/74

IBM Labs in Haifa

2 Contest

Outline

Background

Development methodology

Critical section, semaphores and monitors

Development methodology (revisited)

Threads and locks in Java

Asynchronous message passing and logical time


3/74

IBM Labs in Haifa

3 Contest

Background

In the late 1960 operating systems were organized as concurrentprograms, with processes managing devices and executing user tasks

a process is an abstraction of a processor

process = (code, heap, registers, stack)

thread is a light process, it belongs to a process and shares itsheap. thread = (program, registers, stack)

Registers are scoped to the thread

processes execute one at a time in an interleaved way

Technology evolved to produce a variety of shared memory, messagepassing and communication network multiprocessors

process communication abstracts the available hardwarecommunication

Multiprocessors actually execute in parallel


4/74


5/74

IBM Labs in Haifa

5 Contest

Background (Continued)

Processes communicate using shared variables or messages

Communication requires synchronization to ensure mutual exclusionor condition synchronization

Mutual exclusion - critical section of statements that access shared

objects are not executed at the same time Condition synchronization - a process delays if necessary until a given

condition is true


6/74

IBM Labs in Haifa

6 Contest

Example producer and consumer

Communicate using a shared buffer

The producer (sender) writes to the buffer and the consumer (reader)reads from the buffer

Mutual exclusion is used to ensure that the sender and the receiver do

not access the buffer at the same time Condition synchronization is used to ensure that

a message is not received before it has been sent and

a message is not overwritten before it has been received.


7/74

IBM Labs in Haifa

7 Contest


At run time

The state of a process is the state of its heap (shared variables,shared objects), stack, registers, and hidden variables (e.g., theprogram counter)

Processes create new child processes (fork() - Unix)A process is part of a concurrent program if it communicates with

other processes

The rate of execution of each process is unknown

No assumption should be made on a process rate

Also see bugPatternPreventionAndReview presentation


8/74

IBM Labs in Haifa

8 Contest


At run time A process transforms its state by executing statements

Each statements consists of a sequence of atomic actions that makeindivisible transformationse.g., uninterruptible machine instructions that load and store registersif is executed, you can not observe a state in which Y is not

equal to ZClear understanding of which source level operations are atomic is veryimportantStoring and loading of long and double in Java are not necessarily atomic

(also see the concurrentBugPattern presentation)

The trace/history/interleaving of a particular execution is a sequence ofatomic actions

Even parallel execution can be modeled in this way The effect of executing a set of atomic actions in parallel is equivalent to

executing them in some arbitrary order

The state transformation caused by atomic actions is indivisible and can notbe effected by other actions


9/74

IBM Labs in Haifa

9 Contest

Concurrent execution semantics is definable using a small setof rules

(c1, s1) s2 => (c1 || c2, s1) -> (c2, s2)

(c1, s1) s2 => (, s1) s2

(b, s1) true and (c, s1) s2 => (, s1) s2


10/74

IBM Labs in Haifa

10 Contest

Background scheduling policies

A process is eligible to run when it is not waiting on event

A process can wait for a page to be swapped from the disk

The page can be part of the processes or part of a read file operation

A process can wait in the socket accept() API waiting for a message

to arrive on the socket We will be interested in safety and liveness properties.

Safety nothing bad happen

Mutual exclusion

Absence of deadlock

Livness something good eventually happens

Request for service will eventually be honored


11/74

IBM Labs in Haifa

11 Contest

Background scheduling policies

When several processes are eligible to run

The scheduler determines which one will execute next

Fairness is concerned with guaranteeing that processes get a chance toproceed

Most liveness properties depend on fairness

Scheduling policies

Unconditional fairness eligible processes eventually run

Weak fairness unconditional fair and

If is eligible and B becomes true and remains true thenit eventually executes

Strong fairness unconditional fair and

If is eligible infinitely often then it eventually executes


12/74

IBM Labs in Haifa

12 Contest

Scheduling policies examples

var continue = true

loop:: do continueskip od

stop:: continue = false

Unconditional fairness will ensure progress

giving every one a chance (round robin, time slicing, etc) on a

single processor

execution of both processes on a multiple processors

The above example has no blocking operation, when there are blockingoperations

Every process gets a chance is weakly fair as every delayed

process will eventually see its delay condition is true and proceed


13/74

IBM Labs in Haifa

13 Contest

Scheduling polices examples (continued)

var continue = true, try = false

loop:: do continue try = true; try = false; od

stop::

Strong fairness eventually terminate as try is infinitely often true

Weak fairness not terminate as try is not eventually true

Impossible to device both practical and strongly fair

Alternating on a single processor will be strongly fair but not

practical andGiving every one a chance will not work

On a multiple processor stop might always examine try when it isfalse (in small probabilty)


14/74

IBM Labs in Haifa

14 Contest

Scheduling polices

Avoid ensuring progress by making some condition infinitely often true

Another example if

All processes execute s = s +1, and

Two processes execute 0 s = s -1>,

FCFS (first come first served) policy will ensure all will makeprogress


15/74

IBM Labs in Haifa

15 Contest

Process life cycle

Actually there are more details relating to swapping the process frommain memory

On a single processor only one process is running.

A context switch the single process that is running is put to sleep

and another process is giving the cpu and starts running An interrupt causes a change of control to the interrupt handler,

otherwise the process still runs in the same context

The Unix signal mechanism is an abstraction of hardware interrupts

A process can sleep on an event. It is wakened up by the kernel and

made ready for run only when the event becomes true


16/74

IBM Labs in Haifa

16 Contest

Outline

Background







17/74

IBM Labs in Haifa

17 Contest

The testing/validation problem

The number of possible interleavings is enormous

For (a;b;c;e;f;g)||(h;I;j;k;l;m) of none blocking atomic actions thenumber of possible traces is 12!/(6!*6!) = 924

Testing/reviewing all of the interleaving is out of the question


18/74

IBM Labs in Haifa

18 Contest

Objectives

Demonstrate design through abstraction levels

Abstraction levels are determined by the synchronization primitivesbeing used

Higher abstraction level synchronization primitives ->

lower number of possible interleavingsMistakes are less likely

Validate the design

By reviewing the important interleavings at every abstraction level

Higher abstraction level synchronization primitives are correctlyimplemented by lower abstraction level synchronization primitives

Test an implementation using ConTest


19/74

IBM Labs in Haifa

19 Contest

Abstraction level example

means that i++ is atomic

At a lower level constructor you would specify synchronized(o){i++}

you will have to identify each other location in the program thataccess i and

protect the access using the lock o which is error prone


20/74

IBM Labs in Haifa

20 Contest

Outline

Background







21/74

IBM Labs in Haifa

21 Contest

The critical section scenario

p[i : 1..n]:: do true ->

entry protocol (obtaining a lock)

critical section

exit protocol (releasing a lock)

none-critical section

od


22/74

IBM Labs in Haifa

22 Contest

The critical section scenario (continued)

N processes repeatedly execute a critical section code, then a nonecritical section code

The critical section is preceded by an entry protocol and followed by anexit protocol


23/74

IBM Labs in Haifa

23 Contest

Critical section entry and exit protocol requirements

Mutual exclusion - at most one process at a time is executing its criticalsection (safety)

Absence of deadlock if two or more processes are trying to entertheir critical section at least one will succeed (progress)

Eventual entry a process that is attempting to enter the critical sectionwill eventually succeed (progress)

We assume that a process that enters a critical section eventually exitthe critical section

In practice this is a bug pattern


24/74

IBM Labs in Haifa

24 Contest

Real world description of the ticket algorithm

Some stores/government offices employ the following method to ensurethat customers are serviced in order of arrival

Upon entering the store, a customer draws a number that is largerthan the number held by any other customer

The customer then waits until all customers holding smaller numbershave been serviced

This algorithm is implemented by a number dispenser and by adisplay indicating which customer is being served

If the store has one employee behind the service counter, customers

are served one at a time in their order of arrival


25/74

IBM Labs in Haifa

25 Contest

High level implementation of the ticket algorithm

var number := 1, next := 1, turn[1:n] := ([n], 0)

P[1:1..n]:: do true ->

critical section

non-critical section

od


26/74

IBM Labs in Haifa

26 Contest

Mapping of the previous two abstraction levels (real world andhigh level descriptions)

// customer obtains a ticket

// customers wait their turn

// call for next customer


27/74

IBM Labs in Haifa

27 Contest

Testing/validating the protocol

Even if the synchronization primitives are high level there are typically too manyinterleavings to review

This is addressed by interleaving selection, inductive proof, invariants Assuming process i entered the critical section then

turn[i] == next right after .It is easy to prove that turn[i] turn[j] if i j and turn[i] 0 and turn[j] 0

Thus, as long as the critical section is not exited, any process that will reach will have to wait andat most one process can enter the critical section.

Interleaving selection at a high level we want several processes to access thecritical section together

At a lower level interesting interleavings suggest themselves and then

coverage models are build based on them Finally, during code review specific context switch decisions are made by

the devil advocate based on known bug patternsmore about this in the IRT lecture


28/74

IBM Labs in Haifa

28 Contest

Testing the protocol

Denote the atomic actions above as (a1, b1, c1) by process one and similarly byprocess two

Intuitively, it is enough to let the two processes iterate twice through the criticalsection concurrently.

Thus, it is enough to get all possible interleavings of

(a1, b1, c1, a1, b1, c1) || (a2, b2, c2, a2, b2, c2)

(roughly 1000 interleavings as discussed before)

If a context switch is done with probability after each atomic event the lowestprobability for the occurrence of an interleaving is at least (1/2)^12

Thus, we will need a few hours to cover all of the interelavings (if a run is no

more than a minute).

running it over night using ConTest will be more than enough

This requires automatic checking of correctness and

automatic saving of the seed for replay after failure


29/74

IBM Labs in Haifa

29 Contest

Choosing interleavings to review

Create interleavings that contend on shared resources

Highest level validation plan two or three processes attempt toaccess the critical section concurrently

At this abstraction level create the interesting interleavings by context

switching processes after atomic operations are completed In the example I have done a context switch just before entering the

critical section and again after leaving the critical section

Coverage model (2 * 2 = 4 coverage tasks)

The blocking in to occur and not occur

A context switch to occur right before and right after

Two processes executed the entry protocol concurrently


30/74

IBM Labs in Haifa

30 Contest

Validation using the interleaving review technique

Process 1 Process 2 number next turn[1] turn[2]

1 1 0 0

2 1 1 0

3 1 1 2

blocks

critical section

3 2 1 2


31/74

IBM Labs in Haifa

31 Contest

Validation using the interleaving review technique (Continued)

Process 1 Process 2 number next turn[1] turn[2]

returns

critical section

3 3 1 2


32/74

IBM Labs in Haifa

32 Contest

Pthread implementation of the ticket algorithm

We will review an interleaving at the implementation level

is implemented by

Waiting on an event and

Signaling when the event occurred

Identifying when to signal requires careful review of the design


33/74

IBM Labs in Haifa

33 Contest

Dijkstra algorithm

Process i

**Reminder region**

Try_i

L: flag(i) = 1

while(turn i ) do

if flag(turn) == 0 then turn = i

flag(i) = 2

for j i do

if(flag(j) == 2) then goto L

Crt_i

**Crtical region**Exit _i

Flag(i) = 0

Rem_i


34/74

IBM Labs in Haifa

34 Contest

Dijkstra algorithm (continued)

turn : 1..n, initially arbitrary, on the heap

For every process i, flag(i) : {0, 1, 2}, initially 0

To undersntad a protocol we consider interesting interleavings

For example, turn = 3, process one and two arrive and check

flag(turn) to be zero. As a result both can get to the stage were flagis 2

Will this algorithm work if written as is in Java?


35/74

IBM Labs in Haifa

35 Contest

Real world semaphores

Railroad traffic is synchronized to avoid train collisions

A signal flag that indicates whether the track ahead is clear oroccupied by other trains

As train proceeds, semaphores are set and cleared

Semaphores remaining set far enough behind the last train so thatanother train has time to stop if necessary

Semaphores signal conditions in order to ensure mutually exclusionoccupancy of critical sections of tracks

The critical section of track is able to occupy up to a predefined

number of trains simultaneously


36/74

IBM Labs in Haifa

36 Contest

High level design of a semaphore

A semaphore is an abstract data type that has two operations P() andV()

P() is used to delay until enough V() operations occurred

init defines the gap between P() and V() operations:

nP nV


37/74

IBM Labs in Haifa

37 Contest

Semaphore high level implementation

Thus, 0

an increase in nP by one decreases s by one. The await is added to

keep s none negativeV()::

an increase on nV by one increase s by one. As a result s remainsnone negative

IBM L b i H if


38/74

IBM Labs in Haifa

38 Contest

Semaphores solve the critical section problem

For init = 1 only one train is allowed on the track segment. Thus, thecritical section problem is solved by

var mutex : sem = 1;

P(I : 1..n):: do true P(mutex)critical section

V(mutex)

non-critical section

od

Semaphores can solve various synchronization problems

IBM L b i H if


39/74

IBM Labs in Haifa

39 Contest

A two process barrier

Requirements

Neither process can get past the barrier until both have arrived

The barrier is reusable since both processes will need tosynchronize after each stage of the computation

BARRIER invariant: depart1


40/74

IBM Labs in Haifa

40 Contest

High level solution

Var arrive1=arrive2=depart1=depart2=0

P1:: do true

od

P2:: do true

IBM L b i H if


41/74

IBM Labs in Haifa

41 Contest

Monitors

In traditional concurrent programs portion of the program are declared atomic Atomicity is typically obtained through the use of some lock primitive To understand how shared variables are used one must examine the entire program Traditional, none object oriented, operating systems are examples of the need to

examine the entire programExamining the entire program is bad, too many details, hard to get right

Monitors are an abstract data type that provide encapsulation Monitors shared resources are only accessed by its procedures We say that two code segments interfere if they access shared resources

concurrentlyUsing monitors we prevent interference

Execution of procedures in the same monitor do not overlap Condition variables are used for coordination (wait(cond), notifyAll(cond))

Low level synchronization primitives that enable efficient implementation Monitor design is relatively independent if proper invariants and contracts are defined

Programmer calling a monitor ignores how it is implemented Programmer implementing the monitor ignores how it is used

IBM Labs in Haifa


42/74

IBM Labs in Haifa

42 Contest

Java supports the monitor concept

An object can be implemented as a monitor

Each object in Java is associated a lock

The object shared resources should only be accessed through the classmethods (using Java variables scope rules this can be enforced)

The objects lock can be used to avoid method interference (using the

synchronized keyword to proceed the method declaration)

wait() can be used to wait on event

The condition variable is usually the object instance itself (this)

In addition to its monitor implementation Java has its two layer shared memorymodel, interrupt mechanism and join() mechanism

pthread mutex lock and condition variables synchronization primitives provide away to implement a monitor in C

but hiding is not encouraged by the none object oriented implementation ofpthread

IBM Labs in Haifa


43/74

IBM Labs in Haifa

43 Contest

A big win in testing

My experience is that Java code tend to have the synchronizationprotocol hidden in a class

This is a big win

Review is simplified

Stand alone testing is enabledIn fact we provide this as a service

Give an example of a the HA synchronization protocol

IBM Labs in Haifa


44/74

IBM Labs in Haifa

44 Contest

Design mechanism

We present monitors as a high abstraction level design mechanism

As mentioned Java is geared towards the implementation ofmonitors

Think of a monitor as a class (instance) with additional restrictions

IBM Labs in Haifa


45/74

IBM Labs in Haifa

45 Contest

Monitor syntax

monitor Mname {

declaration of permanent variables; initialization code

method op1(formals1 ) {body of op1};

.

method opN(fomalsN ) {body of opN};

}

IBM Labs in Haifa


46/74

IBM Labs in Haifa

46 Contest

Monitor Requirements

The monitor method calls are the only gates through the monitor wall

syntax MnameInstance.op(arguments )

Monitor methods can access only permanent variables and their localvariables

The second requirement is none trivial as in a typical implementationthe permanent variables are a graph

Permanent variables are initialized before any monitor method isexecuted

Typical concurrent bug pattern - a few threads initializing the monitor

without joining

IBM Labs in Haifa


47/74

IBM Labs in Haifa

47 Contest

Monitor synchronization

At most one process at a time may be executing within any method in the monitor Processes can not interfere when accessing permanent variables Ensured using wait()

Condition variables are used to delay processes until a monitor state satisfies a booleancondition declaration - var c : cond

The value of c is a queue of delayed processes (invisible) In Java this is called the wait set Typically, the condition variable is the lock (monitor) associated with the class instance

(this) In pthreads you define a separate mutex and condition variable

Condition monitors can be used only within the monitor and they are associated withthe monitor implicitly (unlike Java)

To delay until a condition is met the process executes:

while(condition) wait(c); If the condition is true the process is added to cs queue and relinquish the lock

notifyAll(c) awakens all of the process in the queue, they execute at a later time whenthey acquire the monitor lock

On return from notifyAll() and wait() the monitor lock is held

IBM Labs in Haifa


48/74

IBM Labs in Haifa

48 Contest

Caution

As condition monitors should be within the monitor and monitors shouldbe ideally mapped to a class instance

cross class notification should be done with care

Several bug patterns are associated with wait() and notify(), we willdiscuss them later

If notifyAll(c) is performed when the queue is empty it has no effect

Nested monitors calls to different monitors are an issue

If a process calls monitorA.f(); monitorB.g() and then wait it does notrelinquish As lock

Naturally there are several flavors on which processes are run when

they are awakened In Java notify() awakens an arbitrary one and notifyAll() awakens all

of them

Do not use notify()

IBM Labs in Haifa


49/74

IBM Labs in Haifa

49 Contest

How to enforce a monitor in Java

Define a class that meets the following requirements

All of its fields are private. If a field points to additional storage this storage shouldonly be pointed to by the classDo not pass a reference to the constructor and then store it in a structure pointed to by some

class field

The constructor should run in one thread or join all initializing threads (make sure they

terminate) before returning Methods should only access class fields and local variables

All methods should be synchronizedCare should be taken to synchronize on the same lock

Static methods would synchronize on the class lock and none static methods wouldsynchronize on the object lock

Objects used for wait on event should only be accessed from within the monitor

References should not be leaked The discipline part is harder to implement then one thinks as others code is called

Also see the confinement design pattern in [concurrentDesignPattern2]

IBM Labs in Haifa


50/74

IBM Labs in Haifa

50 Contest

A consumer producer example - requirements

A bounded buffer is used for communication between a consumer and aproducer

Consumers place messages in the buffer (deposit)

Delaying if necessary until there is a free buffer slot

Consumers receive messages (fetch)Delaying if necessary until the buffer is not empty

This design pattern is typically used in a client server scenario

See concurrent design pattern book for more examples of the consumerproducer design pattern [concurrentDesignPattern2]

IBM Labs in Haifa


51/74

IBM Labs in Haifa

51 Contest

The sequential invariant

buf[1:n] // the buffer

BUFFER: 1


52/74

IBM Labs in Haifa

52 Contest

High level design of the protocol

Count counts the current number of deposited items. Thus, it is increased byone when a deposit occurs and decreases by one when a fetch occurs

Rear and front points to the buffer so we should take into account that the bufferis bounded when updating them

Changes to the circular queue should be made atomically

deposit

Delay until the buffer is not full

fetch

Delay until the buffer is not empty

Add the necessary delays buf[rear] = data; rear := (rear mod n)+1;

count = count + 1>

0) -> front = (front mod n)+1; count = count 1>

IBM Labs in Haifa


53/74

abs a a

53 Contest

Monitor implementation

Monitor Bounded-Buffer {BUFFER (the invariant)}var buf[1:n] : T; var front := 1, rear := 1, count := 0var not_full : cond // signaled when count < nvar not_empty : cond // signaled when count > 0procedure deposit(data : T){

do count = n -> wait(not_full) odbuffer[rear] := data; rear := (rear mod n) + 1; count := count + 1;notifyAll(not_empty);

}procedure fetch(var result : T){

do count = 0 -> wait(not_empty) od

result := buf[front]; front := (front mod n) + 1; count := count -1;notifyAll(not_full);}}

//Review Java implementation

IBM Labs in Haifa


54/74

54 Contest

Outline

Background




Threads and locks in Java Asynchronous message passing and logical time

IBM Labs in Haifa


55/74

55 Contest

Design guidelines

Use high level primitives

Atomic and

Guarded action st>

Prepare general synchronizationservices for the system located in a

separate class (see picture on the right)

Checking and validation

Interleavings review technique (IRT)

Invariants

IBM Labs in Haifa


56/74

56 Contest

Implementation guidelines

Translation of high level primitives to available primitives

Exact understanding of synchronization primitives

Test yourself see exercises in the end of the presentaiton

Use of IRT and bug pattern based review

Bug pattern understanding

IBM Labs in Haifa


57/74

57 Contest

Testing guidelines

Create black box tests that force contention (use IRT scenarios reviewedin the previous stage)

Use ConTest for noise and concurrent coverage

Use the empty implementation to make sure that the test is strong

enough Repeat the test enough times

Determine success and failure using the invariant, save random seed fordebugging if failed

IBM Labs in Haifa


58/74

58 Contest

General guidelines

Exact understanding of synchronization primitives used

Understanding of concurrent bug-patterns

Understanding of concurrent design patterns

IBM Labs in Haifa


59/74

59 Contest

Outline

Background





IBM Labs in Haifa


60/74

60 Contest

Threads and locks in JavaTerminology and Framework

A Java Virtual Machine (JVM) instance is an operating system process

which might contain several threads of execution

A variable is any location within the Java program that may be stored into

Variables are kept in the heap and are shared by all threads

Every thread has its own working copy of variables that it locally manipulated

performance on a machine with several processors can be improved

The heap contains the master copy of very variable

It is important to understand when changes to the working copy of a variablereach the heaps master copy

The heap also contains locks. There is one lock associated with each object

Threads may compete to acquire a lock

IBM Labs in Haifa


61/74

61 Contest

Rules about locks

Only one thread at a time is permitted to hold the lock

A thread may acquire the same lock multiple times

A thread doesnt relinquish its ownership until a matching number of

unlock operations are performed

IBM Labs in Haifa


62/74

62 Contest

Threads and locks in Java (continued)

Storing and loading of a variable value by a thread from its working copy to the

heap is not atomic

Rules about variables are complicated (see section 17.3 of the specification fordetails).

The main point is to understand - when does a new variable value created

in threads working copy actually gets to the heapIt gets there when a lock is acquired or released

100 threads performing i++, I is global. What are the possible final values ofi?

As mentioned before long and double are not atomic

This limitation might be removed in the future In addition to the monitor support, Java has an interrupt and join mechanisms

In 1.5 thread semantics will change and new higher level synchronizationprimitives will be introduced

IBM Labs in Haifa


63/74

63 Contest

Outline

Background





IBM Labs in Haifa


64/74

64 Contest

Asynchronous message passing

A process appends a message to the end of a channels queue

By executing a send message

The queue is conceptually unbounded

receive delays the receiver until the channel is non-empty

Then the message at the front of the channel is removed andUsed by the receiver

IBM Labs in Haifa


65/74

65 Contest

Channels are like semaphores that carry data

If the channel contains only messages without data

Send and receive are just like V() and P() operations

The number of queued messages is the value of the semaphore

IBM Labs in Haifa


66/74

66 Contest

Filters a sorting network

chan in1(int), in2(int), out(int)

merge:: var v1, v2: int

receive in1(v1); receive in2(v2);

do v1 EOS and v2 EOS // EOS is end of number sequence

if v1


67/74

67 Contest

Why sorted

If a sorted stream of numbers is received in in1 and in2 then

merge will produce a sorted sequence

Thus, by induction the binary tree produces a sorted sequence

IBM Labs in Haifa


68/74

68 Contest

Logical time

No two events get assigned the same logical time

Logical time assigned within a process is strictly increasing

Logical time of any send event is strictly less than it correspondingreceive

ImportanceDebugging

Replay

Global snapshot

Design technique

Adaptation of synchronous algorithms

IBM Labs in Haifa


69/74

69 Contest

Logical time - Lamport

For each process i a local clock

The clock is increased by at least one at every event

The logical time of an event is the value of the clock right after theevent occurred

Paired with the process index as a tie breakerSend

Increment the local clock and attach it to the send message as atimestamp

Receive

New value is the maximum of the timestamp and the lock clock plusone

More algorithms and some application can be found in chapter 18 ofDistributed Algorithms by Nancy

IBM Labs in Haifa


70/74

70 Contest

References

Concurrent Programming, Greorgy R. Andrews, TheBenjamin/Cummings Publishing Company, Inc, 1991

Distributed Algorithms, Nancy A. Lynch, Morgan Kaufmann, 1996

Doug Lea, Concurrent Programming in Java, First Edition, Addison-Wesley, 1997 [concurrentDesignPattern1]

Doug Lea, Concurrent Programming in Java, Second Edition, Addison-Wesley, 2000 [concurrentDesignPattern2]

The second edition is a basically a different book

The Java Language Specification, James Gosling, Bill Joy, Guy Steele,Addison-Wesley, latest addition [javaSpecification]

Also available onlineSupplemented by the Java API at java.sun.com/j2se/1.4.2/docs/api

The Design of the Unix Operating System, Maurice J. Bach, Prentice-Hall, 1986

IBM Labs in Haifa


71/74

71 Contest

Exercises - design

The one-lane bridge cars coming from the north and the south arrive at a one-lane bridge. Cars heading in the same direction can cross the bridge at thesame time, but cars heading in opposite directions cannot. Develop an algorithmto solve this problem

Submit a Java program with a test implemented in main(). Implement the

empty mode and make sure that your test fails in the empty mode. TheJava program should contain at least the online documentation of theprotocol design in the high level language ( B>)

The roller coaster problem - suppose there are n passenger processes and onecar process. The passengers repeatedly wait to take rides in the car, whichholds C passengers, C < n. However, the car only go around the tracks when it

is full. Devise an appropriate protocol Generalize to employ m cars m > 1. Since there is only one track, cars can

not pass each other, i.e., they must finish going around the track in the orderin which they started

IBM Labs in Haifa


72/74

72 Contest

Exercises

See slide called Testing/validating the protocol

See slide called Dijkstra algorithm (continued)

See slide called Channels are like semaphores that carry data

See slide called Filters a sorting network

See slide called Logical time Lamport Correct the Java implementation of the BoundedBuffer class

IBM Labs in Haifa


73/74

73 Contest

Exercises - knowing the synchronization primitives (Java)

100 threads execute i++ where i is a global variable. Describe all possible outcomes The following thread is interrupted while waiting at the blue statement belowtry{

synchronized(foo){foo.wait();

}

}catch(Exception e){};

Is the thread still holding the lock and is the thread interrupt bit turned on at the redstatement above? What are the answers to the same questions if we change theprogram to:

synchronized(foo){

try{foo.wait();

}catch(Exception e){};}

IBM Labs in Haifa


74/74

Exercises - knowing the synchronization primitives (Java)

What happens if one thread executes the following method recursively,e.g., by excecuting factorial(7)

synchronized int factorial(int i){

if(i == 0)return(1);

else

return(i * factorial(i-1));

}