Path: text.usenetserver.com!out02b.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!pd7cy1no!pd7cy2no!shaw.ca!pd7urf2no.POSTED!53ab2750!not-for-mail X-Trace-PostClient-IP: 24.84.208.66 From: paul c User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.databases.theory Subject: Re: What Actually Causes Deadlock References: <1166160839.536968.220270@80g2000cwy.googlegroups.com> In-Reply-To: <1166160839.536968.220270@80g2000cwy.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 74 Message-ID: <1iygh.481770$1T2.240219@pd7urf2no> Date: Fri, 15 Dec 2006 14:28:13 GMT NNTP-Posting-Host: 64.59.144.75 X-Complaints-To: abuse@shaw.ca X-Trace: pd7urf2no 1166192893 64.59.144.75 (Fri, 15 Dec 2006 07:28:13 MST) NNTP-Posting-Date: Fri, 15 Dec 2006 07:28:13 MST Organization: Shaw Residential Internet Xref: usenetserver.com comp.databases.theory:160472 X-Received-Date: Fri, 15 Dec 2006 09:28:12 EST (text.usenetserver.com) Marshall wrote: > Over dinner and some excellent red wine, it occurred to me that > the "folks at home" following some of the commentary on deadlock > might not actually be fully up to speed on what causes deadlock, > and might not be altogether following the ironic mode of speech > in some of the posts, including my own. So I just want to put > out there what really causes deadlock. > > Deadlock is caused when there are *more than one* mutual > exclusion entities, each possessed by a separate thread of > computation, and the threads do not follow a consistent > protocol for acquiring exclusive hold of these entities. Disk > I/O has nothing to do with it; deadlock is entirely possible with > two threads and two locks and no virtual memory or disk > I/O of any kind. > > Note that there has to be at least two, and there has to be > inconsistent order in acquiring the locks. If either condition > does not hold, deadlock is not possible. For example, if > there is only one lock, then deadlock is impossible, no matter > how many threads there are. If there are many locks but only > one thread, then deadlock is impossible no matter how many > locks there are. If there are many threads and many locks, > but there also exists a canonical order to acquire the locks and > every thread will only acquire locks in the canonical order, > then deadlock is impossible. > > The simplest example of deadlock possible: > > Thread A has code that attempts to acquire lock > 1 and if successful attempts to acquire lock 2. > Thread B has code that attempts to acquire lock > 2 and if successful attempts to acquire lock 1. > > No simpler example of deadlock is possible. > > When I was like, 18 years old it occurred to me that > there was a simple lock discipline that would make > deadlock impossible: give every lock a name, and only > acquire locks in alphabetical order. > > In any event, I hope this clears things up. Further questions > will be handled when I'm fully sober. > > For followup reading: > > http://en.wikipedia.org/wiki/Deadlock > http://www.bvwines.com > > > Marshall > Back in the 1970's (and the 1960's too, I guess) every mainframe application programmer who used IBM CICS or IMS DC was aware of that terse bullet list in the wikipedia and were careful to order their accesses, whether they were to dbms, file, TP channel or abstact memory in some agreed-upon order. Similar must have been true of application programmers who used other hardware from the so-called "BUNCH". The big operating system developments of the 1960's had already recognized the problem and even the non-assembler, eg., Cobol, programmers of those days were to some extent programming the bare metal, as it were. I remember several of us scratching our heads around fifteen years ago about a deadlock we had introduced in a multi-process access engine when another old-timer asked what were we playing at. We had become so enamoured with making high-level tools that we had forgotten the old stuff. I suppose the intermittent re-discovery of old knowledge is inevitable as the trend to more and more specialization and componentization continues. p