COP 4600 Operating Systems Fall 2010

Slides:



Advertisements
Similar presentations
COP 4600 Operating Systems Fall 2010 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:30-4:30 PM.
Advertisements

1 Advanced Operating Systems - Spring 2009 Lecture 9 – February 9, 2009 Dan C. Marinescu Office: HEC 439 B. Office.
02/27/2004CSCI 315 Operating Systems Design1 Process Synchronization Deadlock Notice: The slides for this lecture have been largely based on those accompanying.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
COT 5611 Operating Systems Design Principles Spring 2012 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 5:00-6:00 PM.
Chapter 6 Concurrency: Deadlock and Starvation
Modified from Silberschatz, Galvin and Gagne Lecture 13 Chapter 7: Deadlocks.
02/18/2008CSCI 315 Operating Systems Design1 Deadlock Notice: The slides for this lecture have been largely based on those accompanying the textbook Operating.
Synchronization CSCI 444/544 Operating Systems Fall 2008.
COP 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00-6:00 PM.
CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: :30 AM.
SWE202 Review. Processes Process State As a process executes, it changes state – new: The process is being created – running: Instructions are being.
Operating Systems CSE 411 Kernel synchronization, deadlocks Kernel synchronization, deadlocks Dec Lecture 31 Instructor: Bhuvan Urgaonkar.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
COT 5611 Operating Systems Design Principles Spring 2012 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 5:00-6:00 PM.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
This Time - Deadlock Definition Conditions for deadlocks
COP 5611 Operating Systems Spring 2010 Dan C. Marinescu Office: HEC 439 B Office hours: M-Wd 2:00-3:00 PM.
CSE 153 Design of Operating Systems Winter 2015 Midterm Review.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: :30 AM.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: :30 AM.
COP 4600 Operating Systems Fall 2010 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:30-4:30 PM.
Deadlock. Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Deadlocks.
COP 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
Lecture 6 Deadlock 1. Deadlock and Starvation Let S and Q be two semaphores initialized to 1 P 0 P 1 wait (S); wait (Q); wait (Q); wait (S);. signal (S);
COP 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00-6:00 PM.
CSS430 Deadlocks Textbook Ch7
Synchronization Deadlocks and prevention
Chapter 7: Deadlocks.
Operating systems Deadlocks.
COT 4600 Operating Systems Fall 2009
Background on the need for Synchronization
Operating Systems (CS 340 D)
COP 4600 Operating Systems Fall 2010
Operating System: DEADLOCKS
COP 5611 Operating Systems Spring 2010
CGS 3763 Operating Systems Concepts Spring 2013
Chapter 7 Deadlocks.
Chapter 7: Deadlocks.
COP 4600 Operating Systems Spring 2011
COP 4600 Operating Systems Spring 2011
COT 5611 Operating Systems Design Principles Spring 2014
COT 5611 Operating Systems Design Principles Spring 2014
CGS 3763 Operating Systems Concepts Spring 2013
COT 5611 Operating Systems Design Principles Spring 2012
COT 5611 Operating Systems Design Principles Spring 2014
COP 4600 Operating Systems Spring 2011
Chapter 7: Deadlocks.
COT 4600 Operating Systems Spring 2011
COT 5611 Operating Systems Design Principles Spring 2012
Operating systems Deadlocks.
G.Anuradha Ref:- Galvin
Lecture 2 Part 2 Process Synchronization
Chapter 8: Deadlocks.
Deadlocks Session - 13.
Lecture 26 Syed Mansoor Sarwar
CSS430 Deadlocks Textbook Ch8
COP 4600 Operating Systems Fall 2010
COP 5611 Operating Systems Spring 2010
CSE 153 Design of Operating Systems Winter 2019
CSE 542: Operating Systems
COT 5611 Operating Systems Design Principles Spring 2014
CSE 542: Operating Systems
Chapter 8: Deadlocks Deadlock Characterization
Presentation transcript:

COP 4600 Operating Systems Fall 2010 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:30-4:30 PM

Lecture 16 – Thursday October 14, 2010 Last time: Presentation of the paper “DNS Complexity” by Vixie Threads, Virtual memory, Bounded buffers. Virtual Links. Primitives for processor virtualization Threads. The state of a thread. Thread manager. Interrupts. Interrupt handler. Race conditions and locks. Today: Threads Thread and processor layers Processor sharing; Scheduling; Switching the processor from one thread to another – YIELD. Implementation of YIELD and SCHEDULER Next time More on threads and processor sharing. Lecture 16

Lecture 16

Lecture 16

Lecture 16

Switching the processor from one thread to another Thread creation: thread_id ALLOCATE_THREAD(starting_address_of_procedure, address_space_id); YIELD  function implemented by the kernel to allow a thread to wait for an event. Save the state of the current thread Schedule another thread Start running the new thread – dispatch the processor to the new thread YIELD cannot be implemented in a high level language, must be implemented in the machine language. can be called from the environment of the thread, e.g., C, C++, Java allows several threads running on the same processor to wait for a lock. It replaces the busy wait we have used before. Lecture 16

Thread states and state transitions Lecture 16

The processor and the thread table Lecture 16

Lecture 16

Lecture 16

Lecture 16

Lecture 16

Deadlocks Happen quite often in real life and the proposed solutions are not always logical: “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone.” a pearl from Kansas legislation. Deadlock jury. Deadlock legislative body. Lecture 16

Lecture 16

Deadlocks Deadlocks  prevent sets of concurrent threads/processes from completing their tasks. How does a deadlock occur  a set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set. Example semaphores A and B, initialized to 1 P0 P1 wait (A); wait(B) wait (B); wait(A) Aim prevent or avoid deadlocks Lecture 16

Example of a deadlock Traffic only in one direction. Solution  one car backs up (preempt resources and rollback). Several cars may have to be backed up . Starvation is possible. Lecture 16

System model Resource types R1, R2, . . ., Rm (CPU cycles, memory space, I/O devices) Each resource type Ri has Wi instances. Resource access model: request use release Lecture 16

Simultaneous conditions for deadlock Mutual exclusion: only one process at a time can use a resource. Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes. No preemption: a resource can be released only voluntarily by the process holding it (presumably after that process has finished). Circular wait: there exists a set {P0, P1, …, P0} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and P0 is waiting for a resource that is held by P0. Lecture 16

Lecture 16

Implicit assumptions for the correctness of the implementation One sending and one receiving thread. Only one thread updates each shared variable. Sender and receiver threads run on different processors to allow spin locks in and out are implemented as integers large enough so that they do not overflow (e.g., 64 bit integers) The shared memory used for the buffer provides read/write coherence The memory provides before-or-after atomicity for the shared variables in and out The result of executing a statement becomes visible to all threads in program order. No compiler optimization supported Lecture 16

Lecture 16

Lecture 16

One more pitfall of the previous implementation of bounded buffer If in and out are long integers (64 or 128 bit) then a load requires two registers, e.,g, R1 and R2. int “00000000FFFFFFFF” L R1,int /* R1  00000000 L R2,int+1 /* R2  FFFFFFFF Race conditions could affect a load or a store of the long integer. Lecture 16

Lecture 6 Lecture 16 24

Lecture 16