|
In concurrent programming, a deadlock is a situation in which two or more competing actions are each waiting for the other to finish, and thus neither ever does. In a transactional database, a deadlock happens when two processes each within its own transaction updates two rows of information but in the opposite order. For example, process ''A'' updates row ''1'' then row ''2'' in the exact timeframe that process ''B'' updates row ''2'' then row ''1''. Process ''A'' can't finish updating row ''2'' until process ''B'' is finished, but process ''B'' cannot finish updating row ''1'' until process ''A'' is finished. No matter how much time is allowed to pass, this situation will never resolve itself and because of this, database management systems will typically kill the transaction of the process that has done the least amount of work. In an operating system, a deadlock is a situation which occurs when a process or thread enters a waiting state because a resource requested is being held by another waiting process, which in turn is waiting for another resource held by another waiting process. If a process is unable to change its state indefinitely because the resources requested by it are being used by another waiting process, then the system is said to be in a deadlock. Deadlock is a common problem in multiprocessing systems, parallel computing and distributed systems, where software and hardware locks are used to handle shared resources and implement process synchronization. In telecommunication systems, deadlocks occur mainly due to lost or corrupt signals instead of resource contention. ==Examples== Any deadlock situation can be compared to the classic "chicken or egg" problem. It can also be considered a paradoxical "Catch-22" situation. A real world example would be an illogical statute passed by the Kansas legislature in the early 20th century, which stated:〔〔A Treasury of Railroad Folklore, B.A. Botkin & A.F. Harlow, p. 381〕 A simple computer-based example is as follows. Suppose a computer has three CD drives and three processes. Each of the three processes holds one of the drives. If each process now requests another drive, the three processes will be in a deadlock. Each process will be waiting for the "CD drive released" event, which can be only caused by one of the other waiting processes. Thus, it results in a circular chain. Moving onto the source code level, a deadlock can occur even in the case of a single thread and one resource (protected by a mutex). Assume there is a function ''f1'' which does some work on the resource, locking the mutex at the beginning and releasing it after it's done. Next, somebody creates a different function ''f2'' following that pattern on the same resource (lock, do work, release) but decides to include a call to ''f1'' to delegate a part of the job. What will happen is the mutex will be locked once when entering ''f2'' and then again at the call to ''f1'', resulting in a deadlock if the mutex is not reentrant (i.e. the plain "fast mutex" variety). 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Deadlock」の詳細全文を読む スポンサード リンク
|