Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Course Syllabus 1. Introduction - History; Views; Concepts; Structure 2. Process Management - Processes; State + Resources; Threads; Unix implementation.

Similar presentations


Presentation on theme: "1 Course Syllabus 1. Introduction - History; Views; Concepts; Structure 2. Process Management - Processes; State + Resources; Threads; Unix implementation."— Presentation transcript:

1 1 Course Syllabus 1. Introduction - History; Views; Concepts; Structure 2. Process Management - Processes; State + Resources; Threads; Unix implementation of Processes 3. Process Scheduling – Paradigms; Unix; Modeling 4. Inter-Process Communication (IPC) 4. Process Synchronization - Synchronization primitives and their equivalence; Deadlocks 5. Memory Management - Virtual memory; Page replacement algorithms; Segmentation 6. File Systems - Implementation; Directory and space management; Unix file system; Distributed file systems (NFS) 7. Security – General policies and mechanisms; protection models; authentication 8. Distributed issues – Synchronization; Mutual exclusion Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama

2 Inter-Process Communication (IPC)  File: A record stored on a file that can be accessed by name the communicating processes.  Signal: A short system message sent from one process to another, not usually used to store information but instead give commands.  Message Exchange: An anonymous data stream that stores and retrieves information in packets.  Shared memory: Memory region shared by the communicating processes, which are allowed to read and change the content of the shared memory. Processes need to communicate to exchange data and/or synchronize their work. Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 2

3 Inter-Process Communication (IPC)  Message Exchange Mechanism enables processes to communicate without the need to share variables.  It should support at least two primitives:  send(destination, message)  receive(source, message) Process AProcess B Message Passing Module Message Passing Module Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 3

4 Message Format  Header  Message Type  Source & Destination ID  Message Properties  Control Information  Body  The message data Header Body Message Content Message consists of Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 4

5 Messages and Pipes Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 5

6 Message Exchange Mechanism  A general method used for IPC:  Inside the same system/computer  In a networked/distributed system.  Message passing could be  Blocking(synchronous):  The sender blocks until the message is received  The receiver blocks until a message is available  Non-Blocking(asynchronous):  The sender sends the message and continue  The receiver receives a valid message or null Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 6

7 Message Passing Synchronization  The sender  Sends message to multiple destination  Usually expects acknowledgement  The Receiver  Need the received information to proceed  It could be blocked indefinitely if the sender failed or the message was not received. Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 7

8 Send-Received Synchronization The three practical combination:  Blocking send, blocking receive  Non-blocking send, Non-blocking receive  Non-blocking send, Blocking receive Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 8

9 Queue of messages  Order  Usually FIFO  Capacity  Zero: Sender must wait for receiver  Bounder (predefined length): send wait if the queue is full  Unbounded: sender never waits Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 9

10 Direct verse Indirect  Direct  Processes identifier is used for source and destination.  Indirect  Messages are sent to shared mailbox  The receiver picked up the messages from the mailbox  The message are queued within the mailbox Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 10

11 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 11 Mutual exclusion: motivation Race Conditions: Example: Spooler directory with slots; index variables; two processes attempt concurrent access. In points to the next empty slot, Out points to entry holding name of file to print next.... abc.docf.pspaper.ps Process A Process B 4567 Out = 4 In=7

12 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 12 Code using reads/writes only Add_file_to_print_spool (char *name) 1.Local_in := In 2.StoreName(Spool_dir[local_in], name) 3.In := (local_in+1) mod DIR_LEN A scenario proving the above code wrong Process A performs line 1 Process A is preempted by Process B Process B performs Add_file_to_print_spool to completion Process A is re-scheduled, completes lines 2-3. Process B's file is never printed.

13 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 13 The mutual exclusion problem (Dijkstra, 1965) We need to devise a protocol that guarantees mutually exclusive access by processes to a shared resource (such as a file, printer, etc.) or, more generally, a critical section of code How can we avoid such race conditions?

14 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 14 The problem model  Multiple processes  Processes can apply read, write, or stronger operations to shared memory  Completely asynchronous  We assume processes do not fail-stop

15 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 15 Mutual exclusion: formal definition loop forever Remainder code Entry code Critical section (CS) Exit code end loop Remainder code Entry code Exit code CS

16 Slide taken from a presentation by Gadi Taubenfeld, IDC An incorrect naïve solution ( means “waiting for this fork”) 16 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama

17  The solution o A philosopher first gets o only then it tries to take the 2 forks. Dining philosophers: textbook solution Slide taken from a presentation by Gadi Taubenfeld, IDC 17

18 Dining philosophers: textbook solution code #define N 5 #defineTHINKING0 #defineHUNGRY1 #defineEATING2 intstate[N]; semaphore mutex = 1; semaphore s[N]; // per each philosopher int left(int i) { return (i-1) % N;} int right(in it) { return (i+1) % N;} void philosopher(int i) { while (TRUE) { think(); pick_sticks(i); eat(); put_sticks(i); } Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 18

19 Textbook solution code: starvation is possible Eat Block Starvation! Slide taken from a presentation by Gadi Taubenfeld, IDC 19 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama

20 Textbook solution disadvantages  An inefficient solution o reduces to mutual exclusion o not enough concurrency o Starvation possible Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 20

21 The LR Solution  If the philosopher acquires one fork and the other fork is not immediately available, she holds the acquired fork until the other fork is free.  Two types of philosophers: o L -- The philosopher first obtains its left fork and then its right fork. o R -- The philosopher first obtains its right fork and then its left fork.  The LR solution: the philosophers are assigned acquisition strategies as follows: philosopher i is R-type if i is even, L-type if i is odd. R L R L R L Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 21 Slide taken from a presentation by Gadi Taubenfeld, IDC

22 Theorem: The LR solution is starvation-free Assumption: “the fork is fair”. ( means “first fork taken”) R L L R R L 0 1 23 4 6 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 22 Slide taken from a presentation by Gadi Taubenfeld, IDC

23 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 23 Mutex Requirements  Mutual exclusion: No two processes are at the critical section (CS) at the same time  Deadlock-freedom: If processes are trying to enter their critical section, then some process eventually enters the critical section  Starvation-freedom: If a process is trying to enter its critical section, then this process must eventually enter its critical section

24 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 24 Mutual exclusion using critical regions

25 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 25 Brute force solution: disabling interrupts Disable interrupts Do your stuff Enable interrupts Problems  User processes are not allowed to disable interrupts  Disabling interrupts must be done for a very short period of time  Does not solve the problem in a multi-processor system

26 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 26 2-process Mutual Exclusion with a lock variable Program for both processes 1.await lock=0 2.lock:=1 3.CS 4.lock:=0 initially: lock=0 Does the algorithm satisfy mutex? Does it satisfy deadlock-freedom? Does it satisfy starvation-freedom? No Yes No

27 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 27 Mutual Exclusion: strict alternation Does the algorithm satisfy mutex? Does it satisfy deadlock-freedom? Does it satisfy starvation-freedom? Yes No Program for process 0 1.await turn=0 2.CS 3.turn:=1 Program for process 1 1.await turn=1 2.CS 3.turn:=0 initially: turn=0

28 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 28 Mutual Exclusion: flag array Does the algorithm satisfy mutex? Does it satisfy deadlock-freedom? Does it satisfy starvation-freedom? Yes No Program for process 0 1.flags[0]:=true 2.await flags[1]=false 3.CS 4.flags[0]:=false Program for process 1 1.flags[1]:=true 2.await flags[0]=false 3.CS 4.flags[1]:=false bool flags[2] initially {false, false}

29 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 29 Peterson’s 2-process algorithm (Peterson, 1981) initially: b[0]:=false, b[1]:=false, value of turn immaterial Program for process 0 1.b[0]:=true 2.turn:=0 3.await (b[1]=false or turn=1) 4.CS 5.b[0]:=false Program for process 1 1.b[1]:=true 2.turn:=1 3.await (b[0]=false or turn=0) 4.CS 5.b[1]:=false

30 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 30 Schema for Peterson’s 2-process algorithm Indicate participation b[i]:=true Barrier turn:=i Is there contention? b[1-i]=true? yes no Critical Section Exit code b[i]:=false First to cross barrier? turn=1-i? no, maybe yes Synchronization Algorithms and Concurrent Programming, Gadi Taubenfeld © 2006

31 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 31 Peterson’s 2-process algorithm satisfies both mutual-exclusion and starvation-freedom

32 Observations  Shared register : turn (2-valued) read & write by both processes  Two boolean registers : b[0], b[1] process 0 can write b[0], process 1 can write b[1] both can read b[0] & b[1] Can the algorithm be modified to use only single-writer registers ? 32 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama

33 33 Kessels’ 2-process algorithm (1982) encode turn=0: as turn[0] = turn[1] turn=1: as turn[0] ≠ turn[1] initially: b[0]:=false, b[1]:=false, value of turn[i] immaterial Program for process 0 1.b[0]:=true 2.local[0]:=turn[1] 3.turn[0]:=local[0] 4.await (b[1]=false or local[0] ≠ turn[1]) 5.CS 6.b[0]:=false Program for process 1 1.b[1]:=true 2.local[1]:=1 – turn[0] 3.turn[1]:=local[1] 4.await (b[0]=false or local[1] = turn[0]) 5.CS 6.b[1]:=false Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama

34 34 Mutual exclusion for n processes: A tournament tree 0 0 1 0 1 2 3 0 1 2 34 56 7 Level 0 Level 1 Level 2 Processes A tree-node is identified by: [level, node#] Synchronization Algorithms and Concurrent Programming, Gadi Taubenfeld © 2006

35 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 35 N-process mutual exclusion: a tournament tree Program for process i 1.node:=i 2.For level = 0 to log n-1 do 3. id:=node mod 2 4. node:=  node/2  5. b[level,2node+id]:=true 6. turn[level,node]:=id 7. await (b[level,2node+1-id]=false or turn[level,node]=1-id) 8.od 9.CS 10.for level=log n –1 downto 0 do 11. node:=  i/2 level  12. b[level,node]:=false 13.od Variables Per node: b[level, 2node], b[level, 2node+1], turn[level,node] Per process (local): level, node, id.

36 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 36 Fairness: First in First Out (FIFO) entry code exit code critical section remainder  Mutual Exclusion  Deadlock-freedom  Starvation-freedom doorway waiting FIFO: if process p is waiting and process q has not yet started the doorway, then q will not enter the CS before p Synchronization Algorithms and Concurrent Programming, Gadi Taubenfeld © 2006

37 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 37 time Lamport’s Bakery Algorithm 000000 doorway 12345n CS exit 1 1 22 22 1 1 0 2 2 0 3 3 2 2 0 4 4 waiting entry remainder Synchronization Algorithms and Concurrent Programming, Gadi Taubenfeld © 2006

38 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 38 Implementation 1 code of process i, i  {1,..., n} number[i] := 1 + max {number[j] | (1  j  n)} for j := 1 to n (<> i) { await (number[j] = 0)  (number[j] > number[i]) } critical section number[i] := 0 1234n numberinteger 000000 Answer: No, it can deadlock! Does this implementation work? Synchronization Algorithms and Concurrent Programming, Gadi Taubenfeld © 2006

39 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 39 time Implementation 1: deadlock 000000 doorway 12345n CS exit 1 1 22 22 1 1 0 waiting entry remainder deadlock Synchronization Algorithms and Concurrent Programming, Gadi Taubenfeld © 2006

40 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 40 number[i] := 1 + max {number[j] | (1  j  n)} for j := 1 to n (<> i) { await (number[j] = 0)  (number[j],j) < number[i],i) // lexicographical order } critical section number[i] := 0 1234n numberinteger 000000 Answer: It does not satisfy mutual exclusion! Implementation 2 code of process i, i  {1,..., n} Does this implementation work? Synchronization Algorithms and Concurrent Programming, Gadi Taubenfeld © 2006

41 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 41 time Implementation 2: no mutual exclusion 00000 doorway 12345n CS exit 0 1 00 22 1 1 0 22 waiting entry remainder 122 0 Synchronization Algorithms and Concurrent Programming, Gadi Taubenfeld © 2006

42 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 42 The Bakery Algorithm code of process i, i  {1,..., n} 1: choosing[i] := true 2: number[i] := 1 + max {number[j] | (1  j  n)} 3: choosing[i] := false 4: for j := 1 to n do 5: await choosing[j] = false 6: await (number[j] = 0)  (number[j],j)  (number[i],i) 7: od 8: critical section 9: number[i] := 0 1234n choosingbits false numberinteger 000000 false Doorway Waiting Bakery

43 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 43 Lamport’s bakery algorithm satisfies mutual-exclusion, starvation-freedom, and FIFO

44 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 44 Test-and-set(w) do atomically prev:=w w:=1 return prev The test-and-set instruction Program for process i 1.await test&set(v) = 0 2.Critical Section 3.v:=0 initially: v:=0 Mutual exclusion? Yes Deadlock-freedom? No Starvation-freedom? Yes

45 Operating Systems, 2013, Meni Adler, Michael Elhadad, Amnon Meisels & Jihad El-Sama 45 Starvation-free mutex using test-and-set program for process i 1.interested[i]:=true 2.await ( (test-and-set(lock) = 0) || (interested[i]=false) ) 3.CS 4.interested[i]:=false 5.j:=(i+1) % n 6.while (j != i && !interested[j]) j:=++j % n 7.if (j=i) 8. lock:=0 9.else 10. interested[j]:=false boolean lock initially 0, interested[n] initially false


Download ppt "1 Course Syllabus 1. Introduction - History; Views; Concepts; Structure 2. Process Management - Processes; State + Resources; Threads; Unix implementation."

Similar presentations


Ads by Google