Read about Therac-25 at [http://www.ddj.com/cpp/184401630] [http://sunnyday.mit.edu/papers/therac.pdf]
IPC (Interprocess Communication) mechanisms [http://www.faqs.org/docs/kernel_2_4/lki-5.html] [
http://www.comptechdoc.org/os/linux/programming/linux_pgcomm.html]
Processes are concurrent if they exist at the same time.
Processes are asynchronous if NO timing assumptions can be made regarding events that each does. i.e. independent of each other.
Problems can occur if they access shared data. Perhaps the most visible application of concurrency
is in gaming.
Example: Two processes
one counts events one logs the count at regular intervals P1 (ex: count cars that pass, count lines of output) P2 report counts at regular intervals (timer based)
Suppose x is 99 and is shared by P1 and P2 Order of events:1-2-3 or 2-3-1 works as expected Order of events 2-1-3 last event is unreported
P1 (Observer) P2 (Reporter)
loopwait for event
(1) x=x+1end loop
loopsleep(time t)
(2) print x(3) reset x to 0end loop
Worse scenario Could get the following reports:
93 – 95 – 91 – 93 – 181 – 92 – 95.
What happened?
x=x+1 could be translated into machine code as (1a) move, Reg x (1b) add, Reg 1 (1c) store, Reg x
Order of events is 1a-2-3-1b-1c Resetting of x to 0 is lost!!
P1 (Observer) P2 (Reporter)
loopwait for event
(1) x=x+1end loop
loopsleep(time t)
(2) print x(3) reset x to 0end loop
Solution:
if a process is modifying a shared variable, no other process should access it.
This is called Mutual Exclusion. A portion of code that accesses the shared data is
called a critical section. No two processes should be executing their
respective critical sections at the same time.
Solution to the critical section problem must satisfy: Mutual exclusion Progress: Don’t wait if not necessary Bounded waiting: to prevent starvation.
Need to implement entry and exit logic for concurrent programs as shown:While (1){
Entry sectionCritical section
Exit sectionNon critical section
}
Web site contains demos programs in Java that show attempts at Mutual Exclusion among two or more threads.
NOTE: Section 5.7 discusses a little about Java threads and thread scheduling.
Mutual Exclusion. Just establishes the framework and provides a chance to discuss Java Threads.
Algorithm_1 Enforces mutual exclusion Does not satisfy the progress rule forces threads to alternate entries into critical
sections Thus, a thread must wait if it is not its turn.
Algorithm_2 Enforces mutual exclusion Processes not forced to alternate can result in deadlock though may need to use a small time value to show
this.
Algorithm_3. This is the book's Peterson's Solution implemented
in Java. Enforces mutual exclusion Enforces the progress rule Works for 2 processes Does not scale to more than 2 processes.
n-process mutual exclusion algorithm. Developed by Edsgar Dijkstra in 1965.
shared datastatus: array [0..n-1] of (idle, entering, inside)turn : 0..n-1enteringCriticalSection (for process i)Repeat
status[i] = enteringwhile turn i do
if (status[turn] == idle)turn = i
status[i] = insidej = 0while (j < n) and ( (j == i) or status[j] inside)
j = j+1until j == nleavingCriticalSection(for process i)
status[i] = idle
See Dekkers in the collection of java projects. This solution is subject to starvation or indefinite
postponement. Other algorithms that improve on this have been
written by Donald Knuth, DeBruijn, Eisenberg/McGuire and include Lamport’s Bakery algorithm.
Should be able to find examples on the Internet.
Hardware Solutions: testandset(a, b):
Implemented on early IBM machines. This command sets a to b and sets b to true. It’s atomic (uninterruptible) - a machine command.
enteringCriticalSectiontestandset(status, inside)do while (status)
testandset(status, inside)
leavingCriticalSectioninside = false
Many modern systems provide some type of hardware or system level instructions to implement Mutual Exclusion.
Project getAndSet and book figures 6.4 and 6.5 (page 216-217) simulate a hardware instruction with a Java class.
The book example would lock up periodically because the testandset method is not an uninterruptible method. i.e. it is not a hardware instruction.
However, it can be simulated by putting a public synchronized qualifier on each Hardware Data method. This means
Every java object has a lock. Locks are generally ignored. thread must own a lock to call any of the
synchronized methods. If it does not then it waits in a queue until it can own
the lock. Works much like a Monitor (discussed later).
Semaphores:
developed by Dijkstra in 1965 aid to synchronize processes and enforce mutual
exclusion. name give to a device to control occupancy of
sections of railroad tracks. A semaphore is a variable, s that can be operated on
only by two primitives (non-interruptible commands)
Classic primitive operations:
P(s) (For the Dutch word Proberen meaning test)If (s > 0) then s = s – 1
else wait until s > 0
Sometimes instead of a wait, the definition uses a spinlock (busy wait loop). Book does this (p. 218)
Book uses acquire: that is, instead of writing P(s) the book write s.acquire()
V(s) (For the Dutch word Verhogen meaning increment)if a process is suspended, waiting on s, then wake it
else s = s + 1
If P(s) is defined using a spinlock then V(s) need only increment the semaphore value (page 218)
Book uses release: That is, instead of writing V(s) the book writes s.release()
binary semaphore Value is 0 or 1
counting semaphore Value can be any positive integer value.
To enforce Mutual exclusionprocess code::
P(s)critical sectionV(s)
::
Works for any number of processes
Java semaphores
Folder java semaphore shows a java semaphore class from java.util.concurrent.Semaphore.
Similar to book figure 6.7. Folder semaphore shows how a semaphore might be
implemented
Synchronization: The Producer/consumer problem
Producer process creates or produces something Consumer process uses or consumes something Consumer cannot consume what has not been
produced Producer cannot produce until the previous thing has
been consumed. Their critical sections must alternate.
producer/consumer solutionInitially, set s=1 and t=0
Producer Consumer
loop : : P(s) store result V(t) : :forever
loop : : P(t) get result V(s) : :forever
Bounded Buffer problem Producer stores things into a circular queue Consumer consumes from the circular queue Each thing is consumed once Producer cannot store more than the queue can hold Consumer cannot use what has not yet been stored
there Generalization of the producer/consumer problem
Solution is the same as that in the producer-consumer problem except initially set s=N (number of buffers).
variations on the producer consumer problem: Two producers (any order), one consumer, etc. Two producers (fixed order), one consumer, etc. Either of two producers (not both), one consumer,
etc. Various combinations of one producer and two
consumers.
Readers and Writers problem
If a reader wants access, deny iff a writer is active if a writer wants access, deny only iff a reader or
writer is active The following solution is similar to book’s figures
6.15-6.19.
Writer Reader
loop : : P(wrt) write result V(wrt) : :forever
loop : : P(s) readcount++ if readcount == 1 P(wrt) V(s) read data P(s) readcount-- if readcount == 0 V(wrt) V(s) : :Forever
Linux Semaphores: see the Linux demos.