Presentation is loading. Please wait.

Presentation is loading. Please wait.

Avishai Wool lecture 4 - 1 Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.

Similar presentations


Presentation on theme: "Avishai Wool lecture 4 - 1 Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication."— Presentation transcript:

1 Avishai Wool lecture 4 - 1 Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication

2 Avishai Wool lecture 4 - 2 Stand-Alone Solutions (cont.)

3 Avishai Wool lecture 4 - 3 Reminder: Mutual Exclusion Avoid race conditions: make sure that shared variables are not read and written “at the same time”. Not always a shared variable. In general – a critical region.

4 Avishai Wool lecture 4 - 4 Conditions for Mutual Exclusion 1.[Safety] No two processes/threads simultaneously in critical region. 2.[Criticality] No process/thread running outside its critical region may block another process/thread. 3.[Liveness] No process/thread must wait forever to enter its critical region. No assumptions made about speed of CPU or scheduling.

5 Avishai Wool lecture 4 - 5 Solutions that Didn’t Work Simple “lock” shared variable Strict alternation First correct solution by Dekker, 1965 Simpler solution by Petersen, 1981

6 Avishai Wool lecture 4 - 6 Sketch of Thread Int myID; // 0 or 1 While (TRUE) { enter_region(myID); // return when OK to enter critical_region(); // do work in critical region leave_region(myID); }

7 Avishai Wool lecture 4 - 7 Peterson's Algorithm for Mutual Exclusion /* my turn to wait */

8 Avishai Wool lecture 4 - 8 How does it work If nobody in critical region, 0 tries to enter: –turn == process (== 0), so should wait - –… but interested[1] != TRUE  exit spin-lock  [Criticality] condition holds If process 0 in critical region and 1 tries to enter: –turn == process (== 1), so should wait - –… and interested[0] == TRUE  1 stuck in spin-lock  [Safety] condition holds in this case

9 Avishai Wool lecture 4 - 9 Peterson with Race Condition? If both try to enter at same time –Interested[0] ==1, Interested[1] == 1 –Both write “turn”. Suppose 1 writes last. –For 1, turn == process  stuck in spin-lock –For 0, turn != process  exits spin-lock turn used like in alternating solution, but: turn == 1  process 0 allowed to enter. [Safety] holds

10 Avishai Wool lecture 4 - 10 Mutual Exclusion with Hardware TSL instruction (test-and-set-lock): TSL RX, lock RX is a register, lock is a variable in memory Does 2 things: –RX = lock // copy contents of lock into RX –Lock = 1 // set the lock Atomic: no interrupt “in the middle” of TSL.

11 Avishai Wool lecture 4 - 11 Using the TSL instruction Use the busy-wait “lock” algorithm that failed in software

12 Avishai Wool lecture 4 - 12 Priority Inversion with Busy Waiting Assumption: static priority scheduling 2 threads: H with high priority, L with low. L in critical region H tries to enter, stuck in spin-lock H has high priority: keeps getting scheduled. L never gets scheduled  never exists critical region.  H remains stuck.

13 Avishai Wool lecture 4 - 13 The OS should help Use system calls to implement enter_region() Instead of busy-wait, the OS would put the calling thread in BLOCKED state if cannot enter. Advantage: other threads can run, no CPU waste, helps avoid priority inversion.

14 Avishai Wool lecture 4 - 14 Mutual Exclusion with OS support

15 Avishai Wool lecture 4 - 15 Producer-Consumer Problem Two threads share a buffer of size N. (a FIFO Queue from data-structures course) The producer thread puts items in buffer. The consumer thread takes items out of buffer. Producer should block when buffer is full Consumer should block when buffer is empty

16 Avishai Wool lecture 4 - 16 Sleep/Wakeup Mechanism A simple inter-process communication primitive. Two system calls: –Sleep(): make thread blocked until another wakes it. –Wakeup(thread_id): wake a sleeping thread

17 Avishai Wool lecture 4 - 17 Producer/Consumer with Sleep-Wakeup 2. Interrupt 3. Consumer not asleep: Wakeup lost /* local to the thread */ 1. count == 0, consumer scheduled first

18 Avishai Wool lecture 4 - 18 What went wrong? Race condition on count variable. Wakeup sent to process that is not asleep – lost. Consumer remains asleep forever. Producer fills buffer, and goes to sleep (forever).

19 Avishai Wool lecture 4 - 19 Semaphores Improved OS mechanism Invented by E. Dijkstra, 1965. Idea: use an integer variable to count the number of future wakeup() calls.

20 Avishai Wool lecture 4 - 20 Semaphore Operations Down(semaphore): –If semaphore == 0, BLOCK (sleep) // when unblocked  semaphore is > 0 –semaphore-- The down operation is atomic!! Up(semaphore) –semaphore++ –If there are processes blocked on semaphore, one is chosen to complete its down operation.

21 Avishai Wool lecture 4 - 21 Implementing Semaphores Semaphores are implemented via system calls Usually, OS disables interrupts during the Down() and Up() operations to avoid race conditions and guarantee atomicity.

22 Avishai Wool lecture 4 - 22 Semaphores for Mutual Exclusion A 0/1 semaphore  a binary semaphore. int mutex = 1; While (TRUE) { down(mutex); critical_region(); up(mutex); }

23 Avishai Wool lecture 4 - 23 Producer-Consumer with Semaphores

24 Avishai Wool lecture 4 - 24 Two Types of Semaphores The binary semaphore “ mutex ” is used for mutual exclusion. The counting semaphores “ full ” and “ empty ” are for synchronization.

25 Avishai Wool lecture 4 - 25 Semaphores in Win2000 Semaphores are kernel objects. CreateSemaphore() WaitForSingleObject() –This behaves like down() on a semaphore. ReleaseSemaphore() –This is the up() operation.

26 Avishai Wool lecture 4 - 26 Mutexes in Win2000 Mutexes are kernel objects. CreateMutex() WaitForSingleObject() –This behaves like down() (also called mutex_lock() ) on a mutex. ReleaseMutex() –This is the up() (also called mutex_unlock() ) operation.

27 Avishai Wool lecture 4 - 27 Inter-Process Communication (Without shared memory)

28 Avishai Wool lecture 4 - 28 More general communication What if processes need to communicate? no shared memory What if processes reside on separate computers? no shared OS Need to work through a network connection

29 Avishai Wool lecture 4 - 29 Message Passing Simplified mechanism with 2 system calls: send(destination, message) –Sends a message to destination receive(source, message) –Receives a message from source –Source can be ANY if receiver does not care –BLOCK if no message available (or return with error code)

30 Avishai Wool lecture 4 - 30 Producer-Consumer with Message Passing Assumptions: –Messages sent but not received are buffered by OS. –Messages are received in the order they are sent. Consumer send s Producer N “empty” messages. When producer has item, it receive s a message and send s the item.

31 Avishai Wool lecture 4 - 31

32 Avishai Wool lecture 4 - 32 Classical OS Problems Dining Philosophers

33 Avishai Wool lecture 4 - 33 Dining Philosophers Philosophers eat/think Eating needs 2 forks Pick one fork at a time How to prevent deadlock

34 Avishai Wool lecture 4 - 34 A Bad Solution

35 Avishai Wool lecture 4 - 35 Why is this bad? Suppose all philosophers take left fork at the same time. All get stuck trying to take right fork. This is called deadlock.

36 Avishai Wool lecture 4 - 36 A fix? After taking left fork, check if right fork available. If not  put the left fork down, wait, and repeat. Not good: if all start together, they repeat forever: –Pick left fork –Put it down, wait This is called livelock.

37 Avishai Wool lecture 4 - 37 A Randomized Solution while (TRUE) { if (take_fork(i)) { if (take_fork(i+1 % N)) break; //success – have both forks else release_fork(i); } wait(random()); }

38 Avishai Wool lecture 4 - 38 Properties of the Randomized Solution Livelock can only occur if random numbers are the same for all philosophers. High probability of no-livelock – … but livelock is possible. This is what Ethernet does.

39 Avishai Wool lecture 4 - 39 A Safe Solution Protect the procedure with a mutex. No deadlock – … but only one philosopher eating at a time. With 5 philosophers, 2 should be able to eat at the same time.

40 Avishai Wool lecture 4 - 40 Dining Philosophers: Solution part 1

41 Avishai Wool lecture 4 - 41

42 Avishai Wool lecture 4 - 42 Notes Mutex is only over test() and state manipulations, not over eat(). Up(s[i]) can be used from i to itself! Deadlock-free, and allows parallelism

43 Avishai Wool lecture 4 - 43 Concepts for review Peterson’s algorithm TSL instruction (test-and-set-lock) Priority Inversion Producer-Consumer Problem Sleep-Wakeup Semaphore Binary semaphore / mutex Deadlock Dining philosophers


Download ppt "Avishai Wool lecture 4 - 1 Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication."

Similar presentations


Ads by Google