25
November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil Synchronization Tools for Distributed Operating System Survey Paper Team Members: Mazen Hammad Chuck Mann Vrushali Nidgundi Hong Zhang Course: CSE 8343 Advanced Operating Systems Professor: Dr. Mohamed Khalil (Group 2)

November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

Embed Size (px)

Citation preview

Page 1: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 1Instructor: Dr. Khalil

Synchronization Tools for Distributed Operating System

Survey Paper

• Team Members:Mazen HammadChuck MannVrushali Nidgundi Hong Zhang

• Course:CSE 8343 Advanced Operating Systems

• Professor:Dr. Mohamed Khalil

(Group 2)

Page 2: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 2Instructor: Dr. Khalil

Outline

• Mutual Exclusion• Atomicity• Concurrency• Semaphores• Message Passing• Deadlock Handling

Page 3: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 3Instructor: Dr. Khalil

Mutual Exclusion• Mutual-exclusion guarantees that certain sections of

code (critical sections) will not be executed by more than one process simultaneously. These sections of code usually access shared variables in a common store or access shared hardware.

• The standard solution to kernel-level mutual-exclusion in uniprocessor systems is to momentarily disable interrupts to guarantee that the process accessing the sensitive data will not be preempted before the access has been completed. This solution is not available for multiprocessor systems, since processes on these are truly concurrent.

Page 4: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 4Instructor: Dr. Khalil

Mutual Exclusion (Continued)

• A critical section of code is framed by an entry section at the beginning and an exit section at the end; these sections act to grab and release the “lock” on that section.

• One safety property of mutual exclusion is, no more than one process should have its program counter (PC) in the critical code at the same time.

Page 5: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 5Instructor: Dr. Khalil

Mutual Exclusion (Continued)

Different algorithms for implementing mutual exclusion • Centralized Approach: One of the processes in the

system is chosen to coordinate the entry to the critical section.

• Fully Distributed Approach: This algorithm is based on the event ordering scheme.

• Token Passing Approach: Another method of providing mutual exclusion is to circulate a token among the processes in the system.

Page 6: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 6Instructor: Dr. Khalil

Atomicity

• Atomic transaction is a program that must be executed atomically. That is, either all the operations associated with it are executed to completion, or none are performed.

• The two phase commit protocol is used to ensure atomicity.

Page 7: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 7Instructor: Dr. Khalil

Concurrency

Different concurrency control schemes are

modified so that they can be used in a

distributed environment:• Locking Protocols• Timestamping

Page 8: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 8Instructor: Dr. Khalil

Distributed Semaphores

• Semaphores provide a basic synchronization mechanism in uni and multi processor systems

• Supporting semaphores in distributed systems has not received much attention

• Implementation of semaphores very difficult in a distributed system

Page 9: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 9Instructor: Dr. Khalil

Distributed Semaphores (Continued)

• Distributed Semaphore is a semaphore-like mechanism

• It does not require shared memory• Implemented using conditional synchronous

message-passing mechanism

Page 10: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 10Instructor: Dr. Khalil

Distributed Semaphores (Continued)

Synchronization is achieved using LEMMA (MESSAGE QUEUE STABILITY) approach and is used to ensure consistency in distributed database systems

Once the Lemma equation is satisfied then the following things are also satisfied:– A proxy message will not be queued indefinitely– A request message will not be queued indefinitely– Every P request message eventually reaches the

semaphore holder– Two or more nodes will not form a cycle while waiting for a

semaphore– A node’s request for P and V will not form a cycle

Page 11: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 11Instructor: Dr. Khalil

Message Passing

• Minimum set of primitives needed for processes to conduct message passing are:– Send (destination, message)– Receive (source, message)

• Process A sends message to process B with send primitive designating B as destination

• Process B receives message with receive primitive designating A as the source

Page 12: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 12Instructor: Dr. Khalil

Message Passing

Shared Data

Send Message

Process A

Recv Message

Process B

Page 13: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 13Instructor: Dr. Khalil

Common Synchronization Combinations

• Blocking send and blocking receive– Rendezvous – Both sender and receiver are

blocked until the message is delivered– Example – Remote Procedure Calls (RPCs)

• Nonblocking send and blocking receive– Sender can send messages to several different

recipient processes– Receiver that must obtain data from message

before it can do useful work waits for the data

• Nonblocking send and nonblocking receive– Neither process waits but recipient should poll

Page 14: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 14Instructor: Dr. Khalil

Synchronization with Receive MessagesT

ime

Nonblocking Blocking Timeout

pvm_trecv()pvm_recv()pvm_nrecv()Function Called

Time Expired

Message Arrives

Waiting

Waiting

Running

Running

Running

Page 15: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 15Instructor: Dr. Khalil

Synchronization Point

• Group barrier synchronizes a group of processes at a point in time

• Indirect message passing via daemons• Each early member process in a group

performs a virtual blocking receive• Last member process performs a virtual

nonblocking send to all the other processes

Page 16: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 16Instructor: Dr. Khalil

Synchronization with a Group BarrierT

ime

Process 1 Process 2 Process 3

barrier call

barrier call

Synchronization Point

barrier call

Waiting

Waiting

Running

Running

RunningRunning

Note: Syntax of barrier call is pvm_barrier(“g2”,3) where the group name is g2 and the number of processes to rendezvous is 3.

Page 17: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 17Instructor: Dr. Khalil

Deadlock Handling

Processes compete for resources

Page 18: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 18Instructor: Dr. Khalil

Deadlock Characterization& Handling Approaches

• Deadlock will happen if four conditions hold simultaneously– Mutual exclusion– Hold and wait– No preemption– Circular wait

• Deadlock Handling Approaches– Prevention– Avoidance– Detection– Recovery

Page 19: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 19Instructor: Dr. Khalil

Deadlock Prevention

Ensure at least one of these conditions cannot hold• Mutual Exclusion - Not required for sharable

resources, must hold for non-sharable resources• Hold and Wait - Whenever a process requests a

resource, it does not hold any other resources.• No Preemption - Preempt resources held by a

process, which is requesting another resource that cannot be immediately allocated to it.

• Circular Wait - Impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration.

Page 20: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 20Instructor: Dr. Khalil

Deadlock Avoidance

• Wound-Wait Scheme (Preemptive)

Process P0 requests a resource held by process P1,

P0 will be allowed to wait only if it has a larger timestamp

than P1, i.e. P0 is younger than P1. Otherwise, P1 is rolled

back (P1 is wound by P0).

• Wait-Die Scheme (Non-preemptive)

Process P0 requests a resource held by process P1,

P0 will be allowed to wait only if it has a smaller

timestamp than P1, i.e. P0 is older than P1. Otherwise, P0

is rolled back (dies).

Page 21: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 21Instructor: Dr. Khalil

Deadlock Detection

• Centralized Approach• Fully Distributed Approach

Page 22: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 22Instructor: Dr. Khalil

Recovery from Deadlock

• Process Termination– Abort all deadlocked processes– Abort one process at a time until the deadlock cycle is

eliminated– In which order to abort

• Resource Preemption– Selecting a victim - minimize cost– Rollback - return to some safe state, restart process from

that state– Avoid starvation - same process may always be picked as

victim, include number of rollbacks in cost factor

Page 23: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 23Instructor: Dr. Khalil

References

[1] Comer, D. (2000), Internetworking with TCP/IP: Principles, Protocols, and Architectures, 4th Ed., Prentice-Hall, Upper Saddle River, NJ.

[2] Coulouris, G.; Dollimore, J.; Kindberg, T. (2001), Distributed Systems: Concepts and Design, 3rd Ed., Addison-Wesley, Reading, Mass.

[3] El-Rewini, H. (2003), Classroom Lectures, CSE 8380 - Parallel and Distributed Processing, Southern Methodist University, Spring 2003.

[4] El-Rewini, H. and Lewis, T. (1998), Distributed and Parallel Computing, Manning & Prentice Hall, Greenwich, CT.

[5] Fiorini, P. "Distributed Deadlock", University of Southern Maine, Portland, ME.

[6] Holliday, J. and Abbadi, A. “Distributed Deadlock Detection”, Encyclopedia of Distributed Computing, Kluwer Academic Publishers.

[7] Silberschatz, A. and Galvin, P. (1998), "Operating System Concepts", 5th Ed., Addison-Wesley, Read-ing Mass.

[8] Stallings, W. (2001), "Operating Systems: Internals and Design Principles", 4th Ed., Prentice-Hall, Up-per Saddle River, NJ.

[9] Tanenbaum, A. and van Steen, M. (2002), "Distributed Systems: Principles and Paradigms", Prentice-Hall, Upper Saddle River, NJ.

Page 24: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 24Instructor: Dr. Khalil

Questions & Discussion

Page 25: November 22, 2003 SMU School of Engineering Group 2: Hammad, Mann, Nidgundi, & Zhang CSE 8343 Advanced Operating Systems Slide 1 Instructor: Dr. Khalil

November 22, 2003SMU School of Engineering

Group 2: Hammad, Mann, Nidgundi, & ZhangCSE 8343 Advanced Operating Systems

Slide 25Instructor: Dr. Khalil

Thank You!