Re: What Actually Causes Deadlock

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:1iygh.481770$1T2.240219_at_pd7urf2no...
> 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.
> >
[snip]

> > 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.
>

In the mid 1970s I switched from programmer to instructor, and ended up teaching TOPS-10 courses for DEC.
TOPS-10 was the operating system for the DECsystem-10 a.k.a. PDP-10.

Inside the OS, there were these things called "sharable resources", that were not shareable without some locking mechanism. All the programmers in the OS group were familiar with the protocol that had to be followed to prevent deadlock. The protocol was a bit more subtle than alphabetical order, but those details are beside the point here.

One point is that many of these shareable resources had nothing to do with I/O. Often they had to do with managing in core data structures. This confirms what Marshall said.

Another point is that the theory behind lock protocols and deadlock avoidance was very well worked out by that time, but the typical application programmer was stuck in single threaded processes, and so never got a chance to do things wrong.

I could also point out the "RESERVING Clause" in DEC Rdb/VMS "SET TRANSACTION" statements. You could drastically reduce the incidence of deadlocks by careful use of it. However, it was not easy to explain to multiprocessing neophytes, even if they were well seasoned programmers.

> 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.
>

You got that right! Received on Fri Dec 15 2006 - 19:54:08 CET