Upload
avigit-saha
View
245
Download
0
Embed Size (px)
Citation preview
8/4/2019 Concurrent Programing
1/74
Concurrent Programming
Eitan Farchi
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
4/74
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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.
8/4/2019 Concurrent Programing
7/74
IBM Labs in Haifa
7 Contest
Background (Continued)
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/4/2019 Concurrent Programing
8/74
IBM Labs in Haifa
8 Contest
Background (Continued)
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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)
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
16/74
IBM Labs in Haifa
16 Contest
Outline
Background
Development methodology
Critical section, semaphores and monitors
Development methodology (revisited)
Threads and locks in Java
Asynchronous message passing and logical time
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
20/74
IBM Labs in Haifa
20 Contest
Outline
Background
Development methodology
Critical section, semaphores and monitors
Development methodology (revisited)
Threads and locks in Java
Asynchronous message passing and logical time
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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?
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
51/74
IBM Labs in Haifa
51 Contest
The sequential invariant
buf[1:n] // the buffer
BUFFER: 1
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
54/74
54 Contest
Outline
Background
Development methodology
Critical section, semaphores and monitors
Development methodology (revisited)
Threads and locks in Java Asynchronous message passing and logical time
IBM Labs in Haifa
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
59/74
59 Contest
Outline
Background
Development methodology
Critical section, semaphores and monitors
Development methodology (revisited)
Threads and locks in Java Asynchronous message passing and logical time
IBM Labs in Haifa
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
63/74
63 Contest
Outline
Background
Development methodology
Critical section, semaphores and monitors
Development methodology (revisited)
Threads and locks in Java Asynchronous message passing and logical time
IBM Labs in Haifa
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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
8/4/2019 Concurrent Programing
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));
}