Ln4 Concur
-
Upload
oreste2008 -
Category
Documents
-
view
237 -
download
0
Transcript of Ln4 Concur
-
7/27/2019 Ln4 Concur
1/23
University ofPennsylvania
9/19/00 CSE 380 1
Concurrent Processes
CSE 380
Lecture Note 4
Insup Lee
-
7/27/2019 Ln4 Concur
2/23
University ofPennsylvania
9/19/00 CSE 380 2
Concurrent Processes
Implementing a multiprogramming OS requires programming toaccommodate a number of simultaneously executing processes
Multiple-process paradigm also useful for applications (e.g.,
parallel processing, background processing)
Two kinds of parallelism in today's computer systems: Pseudo-parallelism - one CPU supports multiple processes
True parallelism - processes run on multiple CPUs
Two kinds of communication paradigms:
Shared-variable model
Message-passing model
Most systems incorporate a mixture of the two.
-
7/27/2019 Ln4 Concur
3/23
University ofPennsylvania
9/19/00 CSE 380 3
Basic Issues in Concurrent Programming
Programming concurrent processes is difficult anderror-prone bugs are often not reproducible sincethey are timing dependent (known as race condition)
Cooperating concurrent processes need to be
synchronized and/or coordinated to accomplish theirtask.
Basic actions: they are the indivisible (or atomic)actions of a process
Interleaving: other processes may execute anarbitrary number of actions between any twoindivisible actions of one process
-
7/27/2019 Ln4 Concur
4/23
University ofPennsylvania
9/19/00 CSE 380 4
Example: Shared variable problem
Two processes are each reading characters typed at theirrespective terminals
Want to keep a running count of total number of characters
typed on both terminals
A Shared variable V is introduced; each time a character is
typed, a process uses the code:V := V + 1;
to update the count. During testing it is observed that the count
recorded in V is less than the actual number of characters typed.
What happened?
-
7/27/2019 Ln4 Concur
5/23
University ofPennsylvania
9/19/00 CSE 380 5
Example (contd)
The programmer failed to realize that the assignment was notexecuted as a single indivisible action, but rather as the
following sequence of instructions:
MOVE V, r0
INCR r0
MOVE r0, V
-
7/27/2019 Ln4 Concur
6/23
University ofPennsylvania
9/19/00 CSE 380 6
The Producer/Consumer Problem
from time to time, the producer places an item in the buffer
the consumer removes an item from the buffer
careful synchronization required
the consumer must wait if the buffer empty
the producer must wait if the buffer full
typical solution would involve a shared variable count (recallprevious example)
also known as the Bounded Buffer problem
Example: in UNIX shell
myfile.t | eqn | troff
producer
process
consumer
process
P
buffer
C
-
7/27/2019 Ln4 Concur
7/23
University ofPennsylvania
9/19/00 CSE 380 7
Push and Pop example
struct stacknode {int data;
struct stacknode *nextptr;
};
typedef struct stacknode STACKNODE;
typedef STACKNODE *STACKNODEPTR;
void push (STACKNODEPTR *topptr, int info)
{
STACKNODEPTR newptr;
newptr = malloc (sizeof (STACKNODE));newptr->date = info; /* Push 1 */
newptr->nextptr = *topptr; /* Push 2 */
*topptr = newptr; /* Push 3 */
}
-
7/27/2019 Ln4 Concur
8/23
University ofPennsylvania
9/19/00 CSE 380 8
Pop
int pop (STACKNODEPTR *topptr){
STACKNODEPTR tempptr;
int popvalue;
tempptr = *topptr; /* Pop 1 */
popvalue = (*topptr)->data; /* Pop 2 */
*topptr = (*topptr)->nextptr; /* Pop 3 */
free(tempptr);
return popvalue;
}
-
7/27/2019 Ln4 Concur
9/23
University ofPennsylvania
9/19/00 CSE 380 9
The Mutual Exclusion Problem
The previous examples are typical of kind of problem that arises
in operating system programming.
Occurs when more than one process has simultaneous accessto shared data, whose values are supposed to obey someintegrity constraint.
Other examples: airline reservation system, bank transaction
system
Problem generally solved by making access to shared variablesmutually exclusive: at most one process can access sharedvariables at a time
The period of time when one process has exclusive access to
the data is called a critical section.
A process may assume integrity constraint (or data invariant)holds at beginning of critical section and must guarantee that itholds at end.
-
7/27/2019 Ln4 Concur
10/23
University ofPennsylvania
9/19/00 CSE 380 10
Definitions
Deadlock. A situation in which each process in a cycle iswaiting for resources held by the next process in the cycle.
Livelock. A situation in which the algorithm that decides
whether to block an activity fails to reach a decision and
continues to use computational resources.
Starvation. A situation in which a process continue to be
denied a resource that it needs, even though the resource is
being granted to other processes.
Safety Property: bad things will not happen. (e.g., no deadlock)
Liveness Property: good things will eventually happen. (e.g.,no livelock, no starvation)
-
7/27/2019 Ln4 Concur
11/23
University ofPennsylvania
9/19/00 CSE 380 11
The Critical Section Problem
Definition. A critical section is a sequence of activities (orstatements) in a process during which a mutually excluded
resource(s) (either hardware or software) must be accessed.
The critical section problem is to ensure that two concurrent
activities do not access shared data at the same time.
A solution to the mutual exclusion problem must satisfy the
following three requirements:
1 Mutual Exclusion
2 Progress
3 Bounded waiting (no starvation)
-
7/27/2019 Ln4 Concur
12/23
University ofPennsylvania
9/19/00 CSE 380 12
Methods for Mutual Exclusion
1. disable interrupts (hardware solution)
2. switch variables (assume atomic read and write)
3. locks (hardware solution)
4. semaphores (software solution)
5. critical regions and conditional critical sections (language
solution)
6. Hoare's monitor
7. Ada rendezvous
-
7/27/2019 Ln4 Concur
13/23
University ofPennsylvania
9/19/00 CSE 380 13
Disable Interrupts
process A process B... ...
disable interrupts disable interrupts
CS CS
enable interrupts enable interrupts
prevents scheduling during CS
may hinder real-time response (use different priority levels)
All CS's exclude each other even if they do not access thesame variables
This is sometimes necessary (to prevent further interrupts
during interrupt handling)
-
7/27/2019 Ln4 Concur
14/23
University ofPennsylvania
9/19/00 CSE 380 14
Switch Variables
switch := A
process A process B
repeat repeat
... ...
while switch A do while switch B doskip; skip;
/* CS */ /* CS */
switch := B switch := A
1. busy waiting2. danger of long blockage since A and B strictly alternates
3. different CS's can be implemented using different switchvariables
-
7/27/2019 Ln4 Concur
15/23
University ofPennsylvania
9/19/00 CSE 380 15
Shared Variable Solutions
Two processes with shared variables/* initialization section */
Process P[i: 1..2]
do forever
/* entry code *//* critical section */
/* exit code */
/* non-critical section */end
-
7/27/2019 Ln4 Concur
16/23
University ofPennsylvania
9/19/00 CSE 380 16
1st Attempt
1. turn := 1;
2. Process P[1]
3. do forever
4. while turn != 1 do no-op end
5. /* critical section */
6. turn := 2;
7. /* non-critical section *
8. end
-
7/27/2019 Ln4 Concur
17/23
University ofPennsylvania
9/19/00 CSE 380 17
2nd Attempt
1. flag[i: 1..2] := {false, false}
2. Process P[1]
3. do forever
4. while flag[2] do no-op end
5. flag[1] := true;
6. /* critical section */
7. flag[1] := false;
8. /* non-critical section */
9. end
-
7/27/2019 Ln4 Concur
18/23
University ofPennsylvania
9/19/00 CSE 380 18
3rd Attempt
1. flag[i:1..2] := {false, false}
2. Process P[1]
3. do forever
4. flag[1] := true;
5. while flag[2] do no-op end
6. /* critical section */
7. flag[1] := false;
8. /* non-critical section */
9. end
-
7/27/2019 Ln4 Concur
19/23
University ofPennsylvania
9/19/00 CSE 380 19
4th Attempt
1. flag[i:1..2] := {false, false}2. Process P[1]
3. do forever
4. flag[1] := true;
5. while flag[2] do
6. flag[1] := false;
7. while flag[2] do no-op end
8. flag[1] := true;
9. end
10. /* critical section */
11. flag[1] := false;
12. /* non-critical section */
13. end
-
7/27/2019 Ln4 Concur
20/23
University ofPennsylvania
9/19/00 CSE 380 20
Dekkers Algorithm
1. Flag[i:1..2] := {false, false}
2. turn := 1;3. Process P[1]
4. do forever
5. flag[1] := true;
6. while flag[2] do
7. if turn = 2 then
8. flag[1] := false
9. while turn = 2 do no-op end
10. flag[1] := true;
11. end
12. end
13. /* critical section */14. turn := 2;
15. flag[1] := false;
16. /* non-critical section */
17. end
-
7/27/2019 Ln4 Concur
21/23
University ofPennsylvania
9/19/00 CSE 380 21
Correctness of Dekker's Algorithm
Case 1. mutual exclusion is preserved.
Process 1 decides to enter CS only if flag[1] = true.
Only process 1 can change flag[1]
Process 1 inspects flag[2] only while flag[1] = true
Thus, process 1 enters CS only if flag[1] = true andflag[2] = false.
Similarly for process 2.
Therefore, ...
Case 2. mutual blocking cannot occur.
1 Only process 1 wants to enter CS
i.e., flag[1]=true and flag[2]=false
Then, process 1 enters CS regardless of turn
-
7/27/2019 Ln4 Concur
22/23
University ofPennsylvania
9/19/00 CSE 380 22
Correctness (cont.)
2 Both processes 1 and 2 want to enter CS and turn=1
i.e., flag[1]=true and flag[2]=true and turn=1Process 1 loops for flag[2] to set to falseProcess 2 changes flag[2] to false since turn=1Process 2 then loopsSo, process 1 eventually enters CS
3 Only process 2 wants to enter CS
4 Both processes 1 and 2 want to enter CS and turn=2
Properties:
Complex and unclear
Mutual exclusion is preserved
Mutual blocking cannot occur Can be extended for n processes
Starvation impossible
Busy waiting
-
7/27/2019 Ln4 Concur
23/23
University ofPennsylvania
9/19/00 CSE 380 23
Shared Variable Solutions - Discussion
Code depicted is for process P1; symmetric forP2.
Attempt 1: mutex O.K. (Why ?)
but not liveness (What ifP2decides to no longer
enter its critical section ?!)
Attempt 2: mutex not guaranteed(P1 and P2can both find flags false if they
happen to run at same speed)
Attempt 3: mutex, but both P1, P2may find flags true
Attempt 4: again, no progress possible
Dekker's alg: mutex, liveness and bounded waiting!
Note: unlike in attempt 1, "turn" is used only
to break ties.