DOCSLIB.ORG

Classic Synchronization Problems and Deadlock

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Classic Synchronization Problems and Deadlock Value Queue “acquire” op “release” op “broadcast” or “release all” op Lock 0/1 ? Lock Unlock No Block till value = 0; Value = 0 set value = 1 8: Classic Synchronization Semaphore INT Y Wait Signal No? value — Value++ While (getValue()<0){ Problems and Deadlock If value < 0 If value <=0 Signal Add self to queue Wake up one } Condition N/A Y Wait Signal Easy to variable Put self on queue If process on Support Last Modified: queue, wake up A signal all 6/14/2004 11:54:49 AM one Event 0/1 Y Wait Signal Default signal does If Value = 0, put Value = 1 self on queue Wake up all Monitor 0/1 Y Call proc in monitor Return from proc No in monitor -1 -2 Bounded Buffer Classical Synchronization Problems Producer/Consumer r Bounded-Buffer Problem r Finite size buffer (array) in memory shared by (also called Producer-Consumer) multiple processes/threads r Producer threads “produce” an item and place in in the buffer r Readers and Writers Problem r Consumer threads remove an item from the buffer and “consume” it r Why do we need synchronization? r Dining-Philosophers Problem m Shared data = the buffer state m Which parts of buffer are free? Which filled? r What can go wrong? m Producer doesn’t stop when no free spaces; Consumer tries to consume an empty space; Consumer tries to consume a space that is only half-filled by the producer; Two producers try to produce into same space; Two -3 consumers try to consume the same space,… -4 Monitor Solution to Bounded- Monitor Solution to Bounded- Buffer Buffer container_t { //monitor boundedBuffer cont void consumer (){ BOOL free = TRUE; while( allBuffersEmpty()){ void producer (){ item_t item; wait(notAllEmpty) while( allBuffersFull()){ } } wait(notAllFull ) monitor boundedBuffer { } which = findFullBuffer (); conditionVariable notAllFull; consumeItem(which->item); conditionVariable notAllEmpty; which = findFreeBuffer (); which->free = TRUE; container_t buffer[FIXED_SIZE]; which->free = FALSE; numFull--; int numFull = 0; which->item = produceItem(); numFull++ signal(notAllFull); } signal(notAllEmpty ); } } //end Monitor -5 -6 1 Semaphore Solution to Semaphore Solution to Bounded-Buffer Bounded-Buffer semaphore_t mutex; void producer (){ void consumer (){ semaphore_t full; container_t *which; container_t *which; semaphore_t empty; wait(empty); wait(full); wait ( mutex); wait ( mutex); container_t { BOOL free = TRUE; which = findFreeBuffer (); item_t item; which = findFullBuffer (); which->free = FALSE; } consumeItem(which->item); container_t which->item = produceItem(); which->free = TRUE; buffer[FIXED_SIZE]; signal (mutex); signal (mutex); void initBoundedBuffer { signal (full); signal (empty); mutex.value = 1; } } full.value = 0; empty.value = FIXED_SIZE •Can we do better? Lock held while produce/consume? } -7 -8 Semaphore Solution to Readers/ Readers/writers Writers (Reader Preference) semaphore_t mutex; r Shared data area being accessed by multiple void reader (){ semaphore_t okToWrite; processes/threads int numReaders ; wait(mutex ); numReaders ++; r Reader threads look but don’t touch void init{ if (numReaders ==1) m We can allow multiple readers at a time. Why? mutex.value = 1; wait(okToWrite); //not ok to write r Writer threads touch too. okToWrite.value = 1; signal(mutex); numReaders = 0; m If a writer present, no other writers and no readers. } do reading (could pass in pointer to Why? void writer (){ read function) wait( okToWrite); r Is Producer/Consumer a subset of this? do writing (could pass wait(mutex ); m Producers and consumers are both writers in pointer to write function) numReaders --; m Producer = writer type A; Consumer = writer type B and if (numReaders == 0) no readers signal(okToWrite); signal(okToWrite ); //ok to write again } m What might be a reader? Report current num full. signal (mutex); Can we do better? Fairness? -9 } -10 Monitor solution to Semaphore Solution to Readers/ This one favors writers; readers/writers How? Can readers starve? Writers (Fair) Monitor readersWriters { void startWrite() { semaphore_t readCountMutex, incoming, next; int numReaders = 0; BOOL writeInProgress = while (numReaders || int numReaders; writeInProgress){ FALSE; BOOL writeInProgress, readInProgress; int okToWriteQueued = 0; okToWriteQueued++; conditionVariable okToWrite; wait( okToWrite); void init{ conditionVariable okToRead; okToWriteQueued-- ; } readCountMutex.value = 1; void startRead () { writeInProgress = TRUE; incoming.value = 1; while (writeInProgress || } okToWriteQueued){ next.value = 1; wait (okToRead); void finishWrite(){ numReaders = 0; } writeInProgress = FALSE; writeInProgress = FALSE; numReaders ++; if ( okToWriteQueued){ signal( okToRead ); signal( okToWrite); readInProgress = FALSE; } } else { } signal(okToRead); void finishRead(){ } numReaders--; if (numReaders == 0){ } signal( okToWrite); } //end monitor -11 -12 } 2 Semaphore Solution to Readers/ Remember void reader (){ Writers (Fair) wait(incoming); void writer (){ if (!readInProgress) { wait (incoming); wait (next); r Game is obtaining highest possible degree of wait(next); } concurrency and greatest ease of programming wait(readCountMutex); writeInProgress = TRUE; numReaders++; r Tension readInProgress = TRUE; signal(readCountMutex); m Simple and high granularity locks easy to program //Let someone else move on //to wait on next m Simple and high granularity locks often means low //If next on incoming is signal(incoming); //writer will block on next concurrency //If reader will come in signal(incoming); do writing r Getting more concurrency means do reading m Finer granularity locks, more locks writeInProgress = FALSE; m if (next.value == 0){ wait(readCountMutex); More complicated rules for concurrent access numReaders--; signal (next); if (numReaders == 0){ } readInProgress = FALSE; } if (next.value == 0){ signal (next); } } signal(readCountMutex); -13 -14 Semaphore Solution to Dining Dining-Philosophers Problem Philosophers Problem? //array of chopsticks, chopstick i is philosopher 0 gets chopstick 0 to the right of philosopher i philosopher 1 gets chopstick 1 void philosophersLife(int i){ …. semaphore_t while (1) { int rightChopstick, leftChopstick; philosopher N gets chopstick N chopstick[NUM_PHILOSOPHERS]; think(); //figure out which chopsticks I need Deadlock! Solution? rightChopstick = i; void init(){ leftChopstick = i -1+ NUM_PHILOSOPHERS % NUM_PHILOSOPERS; //grab chopsticks for (i=0; i< NUM_PHILOSOPHERS; i++) wait(chopstick[rightChopstick]) wait(chopstick[leftChopstick ]); chopstick[i].value = 1; eat(); } //putdown chopsticks signal(chopstick[ rightChopstick]) signal(chopstick[ leftChopstick]); } } -15 -16 Deadlock Fixing Dining Philosophers r Deadlock exists in a set of r Make philosophers grab both chopsticks processes/threads when all they need atomically processes/threads in the set are waiting m Maybe pass around a token (lock) saying who for an event that can only be caused by can grab chopsticks another process in the set (which is also m Get a global lock before can lock any chopsticks waiting!). r Make a philosopher give up a chopstick r Dining Philosophers is a perfect example. r Others? Each holds one chopstick and will wait forever for the other. -17 -18 3 Cycle in Resource Allocation Resource Allocation Graph Graph Philosopher 1 has chopstick 1 and wants chopstick 0 r Deadlock can be described through a resource allocation graph Chopstick 0 Philosopher 1 Chopstick 1 r Each node in graph represents a Philosopher process/thread or a resource Cycle: P0, C3, P3, C2, P2, 2 has chopstick 2 Philosopher 0 C1, P1, C0, P0 Philosopher 2 r An edge from node P to R indicates that and wants process P had requested resource R chopstick 1 r An edge from node R to node P indicates Chopstick 3 Chopstick 2 that process P holds resource R Philosopher 0 has Philosopher 3 r If graph has cycle, deadlock may exist. If chopstick 0 and wants Philosopher 3 has chopstick 3 chopstick 3 graph has no cycle, deadlock cannot exist. and wants chopstick 2 wait(chopstick[i]) wait(chopstick[(i-1) % NUM_PHILOSOPHERS]) -19 -20 Better Semaphore Solution to No Cycle in Resource Allocation Dining Philosophers Graph Chopstick 0 Philosopher 1 Chopstick 1 void philosophersLife(int i){ Always wait for low chopstick first No cycle! while (1) { No deadlock! think(); Why better? if ( rightChopstick < leftChopstick}{ This is not the Philosopher 2 Philosopher 0 wait(chopstick[rightChopstick ]); One philosopher only possible wait(chopstick[leftChopstick]); reaches right first when outcome. P1 } else { all others reach left could get wait(chopstick[leftChopstick]); chopstick 0 Chopstick 3 wait(chopstick[rightChopstick ]); Two philsophers reach first, similarly Chopstick 2 } for same one and one will P3 could get Philosopher 3 lose; The one who wins chopstick 3 eat(); will get both chopsticks first. and finish – allowing Regardless, if ( rightChopstick < leftChopstick}{ signal( rightChopstick); everyone to finish someone will wait(chopstick[rightChopstick ]); signal( leftChopstick); eventually get both their wait(chopstick[leftChopstick]); chopsticks and } else { } No circular wait! No be able to wait(chopstick[leftChopstick]); wait(chopstick[rightChopstick ]); } deadlock!! finish -21 } -22 Conditions for Deadlock Deadlock Prevention r Deadlock can exist only if the following four r Four necessary and sufficient conditions conditions are met; for deadlock m Mutual Exclusion – some resource must be held m Mutual Exclusion exclusively m Hold and Wait m Hold and Wait – some process must be holding one resource and waiting for another m No
Load more

Recommended publications
  • Deadlock: Why Does It Happen? CS 537 Andrea C
    UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department Deadlock: Why does it happen? CS 537 Andrea C. Arpaci-Dusseau Introduction to Operating Systems Remzi H. Arpaci-Dusseau Informal: Every entity is waiting for resource held by another entity; none release until it gets what it is Deadlock waiting for Questions answered in this lecture: What are the four necessary conditions for deadlock? How can deadlock be prevented? How can deadlock be avoided? How can deadlock be detected and recovered from? Deadlock Example Deadlock Example Two threads access two shared variables, A and B int A, B; Variable A is protected by lock x, variable B by lock y lock_t x, y; How to add lock and unlock statements? Thread 1 Thread 2 int A, B; lock(x); lock(y); A += 10; B += 10; lock(y); lock(x); Thread 1 Thread 2 B += 20; A += 20; A += 10; B += 10; A += B; A += B; B += 20; A += 20; unlock(y); unlock(x); A += B; A += B; A += 30; B += 30; A += 30; B += 30; unlock(x); unlock(y); What can go wrong?? 1 Representing Deadlock Conditions for Deadlock Two common ways of representing deadlock Mutual exclusion • Vertices: • Resource can not be shared – Threads (or processes) in system – Resources (anything of value, including locks and semaphores) • Requests are delayed until resource is released • Edges: Indicate thread is waiting for the other Hold-and-wait Wait-For Graph Resource-Allocation Graph • Thread holds one resource while waits for another No preemption “waiting for” wants y held by • Resources are released voluntarily after completion T1 T2 T1 T2 Circular
    [Show full text]
  • The Dining Philosophers Problem Cache Memory
    The Dining Philosophers Problem Cache Memory 254 The dining philosophers problem: definition It is an artificial problem widely used to illustrate the problems linked to resource sharing in concurrent programming. The problem is usually described as follows. • A given number of philosopher are seated at a round table. • Each of the philosophers shares his time between two activities: thinking and eating. • To think, a philosopher does not need any resources; to eat he needs two pieces of silverware. 255 • However, the table is set in a very peculiar way: between every pair of adjacent plates, there is only one fork. • A philosopher being clumsy, he needs two forks to eat: the one on his right and the one on his left. • It is thus impossible for a philosopher to eat at the same time as one of his neighbors: the forks are a shared resource for which the philosophers are competing. • The problem is to organize access to these shared resources in such a way that everything proceeds smoothly. 256 The dining philosophers problem: illustration f4 P4 f0 P3 f3 P0 P2 P1 f1 f2 257 The dining philosophers problem: a first solution • This first solution uses a semaphore to model each fork. • Taking a fork is then done by executing a operation wait on the semaphore, which suspends the process if the fork is not available. • Freeing a fork is naturally done with a signal operation. 258 /* Definitions and global initializations */ #define N = ? /* number of philosophers */ semaphore fork[N]; /* semaphores modeling the forks */ int j; for (j=0, j < N, j++) fork[j]=1; Each philosopher (0 to N-1) corresponds to a process executing the following procedure, where i is the number of the philosopher.
    [Show full text]
  • CSC 553 Operating Systems Multiple Processes
    CSC 553 Operating Systems Lecture 4 - Concurrency: Mutual Exclusion and Synchronization Multiple Processes • Operating System design is concerned with the management of processes and threads: • Multiprogramming • Multiprocessing • Distributed Processing Concurrency Arises in Three Different Contexts: • Multiple Applications – invented to allow processing time to be shared among active applications • Structured Applications – extension of modular design and structured programming • Operating System Structure – OS themselves implemented as a set of processes or threads Key Terms Related to Concurrency Principles of Concurrency • Interleaving and overlapping • can be viewed as examples of concurrent processing • both present the same problems • Uniprocessor – the relative speed of execution of processes cannot be predicted • depends on activities of other processes • the way the OS handles interrupts • scheduling policies of the OS Difficulties of Concurrency • Sharing of global resources • Difficult for the OS to manage the allocation of resources optimally • Difficult to locate programming errors as results are not deterministic and reproducible Race Condition • Occurs when multiple processes or threads read and write data items • The final result depends on the order of execution – the “loser” of the race is the process that updates last and will determine the final value of the variable Operating System Concerns • Design and management issues raised by the existence of concurrency: • The OS must: – be able to keep track of various processes
    [Show full text]
  • Supervision 1: Semaphores, Generalised Producer-Consumer, and Priorities
    Concurrent and Distributed Systems - 2015–2016 Supervision 1: Semaphores, generalised producer-consumer, and priorities Q0 Semaphores (a) Counting semaphores are initialised to a value — 0, 1, or some arbitrary n. For each case, list one situation in which that initialisation would make sense. (b) Write down two fragments of pseudo-code, to be run in two different threads, that experience deadlock as a result of poor use of mutual exclusion. (c) Deadlock is not limited to mutual exclusion; it can occur any time its preconditions (especially hold-and-wait, cyclic dependence) occur. Describe a situation in which two threads making use of semaphores for condition synchronisation (e.g., in producer-consumer) can deadlock. int buffer[N]; int in = 0, out = 0; spaces = new Semaphore(N); items = new Semaphore(0); guard = new Semaphore(1); // for mutual exclusion // producer threads while(true) { item = produce(); wait(spaces); wait(guard); buffer[in] = item; in = (in + 1) % N; signal(guard); signal(items); } // consumer threads while(true) { wait(items); wait(guard); item = buffer[out]; out =(out+1) % N; signal(guard); signal(spaces); consume(item); } Figure 1: Pseudo-code for a producer-consumer queue using semaphores. 1 (d) In Figure 1, items and spaces are used for condition synchronisation, and guard is used for mutual exclusion. Why will this implementation become unsafe in the presence of multiple consumer threads or multiple producer threads, if we remove guard? (e) Semaphores are introduced in part to improve efficiency under contention around critical sections by preferring blocking to spinning. Describe a situation in which this might not be the case; more generally, under what circumstances will semaphores hurt, rather than help, performance? (f) The implementation of semaphores themselves depends on two classes of operations: in- crement/decrement of an integer, and blocking/waking up threads.
    [Show full text]
  • Q1. Multiple Producers and Consumers
    CS39002: Operating Systems Lab. Assignment 5 Floating date: 29/2/2016 Due date: 14/3/2016 Q1. Multiple Producers and Consumers Problem Definition: You have to implement a system which ensures synchronisation in a producer-consumer scenario. You also have to demonstrate deadlock condition and provide solutions for avoiding deadlock. In this system a main process creates 5 producer processes and 5 consumer processes who share 2 resources (queues). The producer's job is to generate a piece of data, put it into the queue and repeat. At the same time, the consumer process consumes the data i.e., removes it from the queue. In the implementation, you are asked to ensure synchronization and mutual exclusion. For instance, the producer should be stopped if the buffer is full and that the consumer should be blocked if the buffer is empty. You also have to enforce mutual exclusion while the processes are trying to acquire the resources. Manager (manager.c): It is the main process that creates the producers and consumer processes (5 each). After that it periodically checks whether the system is in deadlock. Deadlock refers to a specific condition when two or more processes are each waiting for another to release a resource, or more than two processes are waiting for resources in a circular chain. Implementation : The manager process (manager.c) does the following : i. It creates a file matrix.txt which holds a matrix with 2 rows (number of resources) and 10 columns (ID of producer and consumer processes). Each entry (i, j) of that matrix can have three values: ● 0 => process i has not requested for queue j or released queue j ● 1 => process i requested for queue j ● 2 => process i acquired lock of queue j.
    [Show full text]
  • Deadlock-Free Oblivious Routing for Arbitrary Topologies
    Deadlock-Free Oblivious Routing for Arbitrary Topologies Jens Domke Torsten Hoefler Wolfgang E. Nagel Center for Information Services and Blue Waters Directorate Center for Information Services and High Performance Computing National Center for Supercomputing Applications High Performance Computing Technische Universitat¨ Dresden University of Illinois at Urbana-Champaign Technische Universitat¨ Dresden Dresden, Germany Urbana, IL 61801, USA Dresden, Germany [email protected] [email protected] [email protected] Abstract—Efficient deadlock-free routing strategies are cru- network performance without inclusion of the routing al- cial to the performance of large-scale computing systems. There gorithm or the application communication pattern. In reg- are many methods but it remains a challenge to achieve lowest ular operation these values can hardly be achieved due latency and highest bandwidth for irregular or unstructured high-performance networks. We investigate a novel routing to network congestion. The largest gap between real and strategy based on the single-source-shortest-path routing al- idealized performance is often in bisection bandwidth which gorithm and extend it to use virtual channels to guarantee by its definition only considers the topology. The effective deadlock-freedom. We show that this algorithm achieves min- bisection bandwidth [2] is the average bandwidth for routing imal latency and high bandwidth with only a low number messages between random perfect matchings of endpoints of virtual channels and can be implemented in practice. We demonstrate that the problem of finding the minimal number (also known as permutation routing) through the network of virtual channels needed to route a general network deadlock- and thus considers the routing algorithm.
    [Show full text]
  • Scalable Deadlock Detection for Concurrent Programs
    Sherlock: Scalable Deadlock Detection for Concurrent Programs Mahdi Eslamimehr Jens Palsberg UCLA, University of California, Los Angeles, USA {mahdi,palsberg}@cs.ucla.edu ABSTRACT One possible schedule of the program lets the first thread We present a new technique to find real deadlocks in con- acquire the lock of A and lets the other thread acquire the current programs that use locks. For 4.5 million lines of lock of B. Now the program is deadlocked: the first thread Java, our technique found almost twice as many real dead- waits for the lock of B, while the second thread waits for locks as four previous techniques combined. Among those, the lock of A. 33 deadlocks happened after more than one million com- Usually a deadlock is a bug and programmers should avoid putation steps, including 27 new deadlocks. We first use a deadlocks. However, programmers may make mistakes so we known technique to find 1275 deadlock candidates and then have a bug-finding problem: provide tool support to find as we determine that 146 of them are real deadlocks. Our tech- many deadlocks as possible in a given program. nique combines previous work on concolic execution with a Researchers have developed many techniques to help find new constraint-based approach that iteratively drives an ex- deadlocks. Some require program annotations that typically ecution towards a deadlock candidate. must be supplied by a programmer; examples include [18, 47, 6, 54, 66, 60, 42, 23, 35]. Other techniques work with unannotated programs and thus they are easier to use. In Categories and Subject Descriptors this paper we focus on techniques that work with unanno- D.2.5 Software Engineering [Testing and Debugging] tated Java programs.
    [Show full text]
  • Routing on the Channel Dependency Graph
    TECHNISCHE UNIVERSITÄT DRESDEN FAKULTÄT INFORMATIK INSTITUT FÜR TECHNISCHE INFORMATIK PROFESSUR FÜR RECHNERARCHITEKTUR Routing on the Channel Dependency Graph: A New Approach to Deadlock-Free, Destination-Based, High-Performance Routing for Lossless Interconnection Networks Dissertation zur Erlangung des akademischen Grades Doktor rerum naturalium (Dr. rer. nat.) vorgelegt von Name: Domke Vorname: Jens geboren am: 12.09.1984 in: Bad Muskau Tag der Einreichung: 30.03.2017 Tag der Verteidigung: 16.06.2017 Gutachter: Prof. Dr. rer. nat. Wolfgang E. Nagel, TU Dresden, Germany Professor Tor Skeie, PhD, University of Oslo, Norway Multicast loops are bad since the same multicast packet will go around and around, inevitably creating a black hole that will destroy the Earth in a fiery conflagration. — OpenSM Source Code iii Abstract In the pursuit for ever-increasing compute power, and with Moore’s law slowly coming to an end, high- performance computing started to scale-out to larger systems. Alongside the increasing system size, the interconnection network is growing to accommodate and connect tens of thousands of compute nodes. These networks have a large influence on total cost, application performance, energy consumption, and overall system efficiency of the supercomputer. Unfortunately, state-of-the-art routing algorithms, which define the packet paths through the network, do not utilize this important resource efficiently. Topology- aware routing algorithms become increasingly inapplicable, due to irregular topologies, which either are irregular by design, or most often a result of hardware failures. Exchanging faulty network components potentially requires whole system downtime further increasing the cost of the failure. This management approach becomes more and more impractical due to the scale of today’s networks and the accompanying steady decrease of the mean time between failures.
    [Show full text]
  • The Deadlock Problem
    The deadlock problem n A set of blocked processes each holding a resource and waiting to acquire a resource held by another process. n Example n locks A and B Deadlocks P0 P1 lock (A); lock (B) lock (B); lock (A) Arvind Krishnamurthy Spring 2004 n Example n System has 2 tape drives. n P1 and P2 each hold one tape drive and each needs another one. n Deadlock implies starvation (opposite not true) The dining philosophers problem Deadlock Conditions n Five philosophers around a table --- thinking or eating n Five plates of food + five forks (placed between each n Deadlock can arise if four conditions hold simultaneously: plate) n Each philosopher needs two forks to eat n Mutual exclusion: limited access to limited resources n Hold and wait void philosopher (int i) { while (TRUE) { n No preemption: a resource can be released only voluntarily think(); take_fork (i); n Circular wait take_fork ((i+1) % 5); eat(); put_fork (i); put_fork ((i+1) % 5); } } Resource-allocation graph Resource-Allocation & Waits-For Graphs A set of vertices V and a set of edges E. n V is partitioned into two types: n P = {P1, P2, …, Pn }, the set consisting of all the processes in the system. n R = {R1, R2, …, Rm }, the set consisting of all resource types in the system (CPU cycles, memory space, I/O devices) n Each resource type Ri has Wi instances. n request edge – directed edge P1 ® Rj Resource-Allocation Graph Corresponding wait-for graph n assignment edge – directed edge Rj ® Pi 1 Deadlocks with multiple resources Another example n P1 is waiting for P2 or P3, P3 is waiting for P1 or P4 P1 is waiting for P2, P2 is waiting for P3, P3 is waiting for P1 or P2 n Is there a deadlock situation here? Is this a deadlock scenario? Announcements Methods for handling deadlocks th n Midterm exam on Feb.
    [Show full text]
  • Deadlock Problem Mutex T M1, M2;
    The deadlock problem mutex_t m1, m2; void p1 (void *ignored) { lock (m1); lock (m2); /* critical section */ unlock (m2); unlock (m1); } void p2 (void *ignored) { lock (m2); lock (m1); /* critical section */ unlock (m1); unlock (m2); } • This program can cease to make progress – how? • Can you have deadlock w/o mutexes? 1/15 More deadlocks • Same problem with condition variables - Suppose resource 1 managed by c1, resource 2 by c2 - A has 1, waits on c2, B has 2, waits on c1 • Or have combined mutex/condition variable deadlock: - lock (a); lock (b); while (!ready) wait (b, c); unlock (b); unlock (a); - lock (a); lock (b); ready = true; signal (c); unlock (b); unlock (a); • One lesson: Dangerous to hold locks when crossing abstraction barriers! - I.e., lock (a) then call function that uses condition variable 2/15 Deadlocks w/o computers • Real issue is resources & how required • E.g., bridge only allows traffic in one direction - Each section of a bridge can be viewed as a resource. - If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback). - Several cars may have to be backed up if a deadlock occurs. - Starvation is possible. 3/15 Deadlock conditions 1. Limited access (mutual exclusion): - Resource can only be shared with finite users. 2. No preemption: - once resource granted, cannot be taken away. 3. Multiple independent requests (hold and wait): - don’t ask all at once (wait for next resource while holding current one) 4. Circularity in graph of requests • All of 1–4 necessary for deadlock to occur • Two approaches to dealing with deadlock: - pro-active: prevention - reactive: detection + corrective action 4/15 Prevent by eliminating one condition 1.
    [Show full text]
  • Deadlock Immunity: Enabling Systems to Defend Against Deadlocks
    Deadlock Immunity: Enabling Systems To Defend Against Deadlocks Horatiu Jula, Daniel Tralamazza, Cristian Zamfir, George Candea Dependable Systems Laboratory EPFL Switzerland Abstract new executions that were not covered by prior testing. Deadlock immunity is a property by which programs, Furthermore, modern systems accommodate extensions once afflicted by a given deadlock, develop resistance written by third parties, which can introduce new dead- against future occurrences of that and similar deadlocks. locks into the target systems (e.g., Web browser plugins, We describe a technique that enables programs to auto- enterprise Java beans). matically gain such immunity without assistance from Debugging deadlocks is hard—merely seeing a dead- programmers or users. We implemented the technique lock happen does not mean the bug is easy to fix. for both Java and POSIX threads and evaluated it with Deadlocks often require complex sequences of low- several real systems, including MySQL, JBoss, SQLite, probability events to manifest (e.g., timing or workload Apache ActiveMQ, Limewire, and Java JDK. The results dependencies, presence or absence of debug code, com- demonstrate effectiveness against real deadlock bugs, piler optimization options), making them hard to repro- while incurring modest performance overhead and scal- duce and diagnose. Sometimes deadlocks are too costly ing to 1024 threads. We therefore conclude that deadlock to fix, as they entail drastic redesign. Patches are error- immunity offers programmers and users an attractive tool prone: many concurrency bug fixes either introduce new for coping with elusive deadlocks. bugs or, instead of fixing the underlying bug, merely de- crease the probability of occurrence [16]. 1 Introduction We expect the deadlock challenge to persist and likely Writing concurrent software is one of the most challeng- become worse over time: On the one hand, software ing endeavors faced by software engineers, because it re- systems continue getting larger and more complex.
    [Show full text]
  • Edsger Wybe Dijkstra
    In Memoriam Edsger Wybe Dijkstra (1930–2002) Contents 0 Early Years 2 1 Mathematical Center, Amsterdam 3 2 Eindhoven University of Technology 6 3 Burroughs Corporation 8 4 Austin and The University of Texas 9 5 Awards and Honors 12 6 Written Works 13 7 Prophet and Sage 14 8 Some Memorable Quotations 16 Edsger Wybe Dijkstra, Professor Emeritus in the Computer Sciences Department at the University of Texas at Austin, died of cancer on 6 August 2002 at his home in Nuenen, the Netherlands. Dijkstra was a towering figure whose scientific contributions permeate major domains of computer science. He was a thinker, scholar, and teacher in renaissance style: working alone or in a close-knit group on problems of long-term importance, writing down his thoughts with exquisite precision, educating students to appreciate the nature of scientific research, and publicly chastising powerful individuals and institutions when he felt scientific integrity was being compromised for economic or political ends. In the words of Professor Sir Tony Hoare, FRS, delivered by him at Dijkstra’s funeral: Edsger is widely recognized as a man who has thought deeply about many deep questions; and among the deepest questions is that of traditional moral philosophy: How is it that a person should live their life? Edsger found his answer to this question early in his life: He decided he would live as an academic scientist, conducting research into a new branch of science, the science of computing. He would lay the foundations that would establish computing as a rigorous scientific discipline; and in his research and in his teaching and in his writing, he would pursue perfection to the exclusion of all other concerns.
    [Show full text]