A Deadlock Holiday
What to do now there's no Moore's Law?
Stob Moore's Law, I need hardly remind a top-notch industry professional like you, states that as the density of silicon circuitry doubles, the probability of you not being able to find some sensibly-priced extra memory to fit your old lappy approaches 1.0.
In recent times it has become generally admitted that, if this well-known observation has not yet quite joined Elvis, it is at the very least fiddling determinedly with the fire exit door. Instead of increasingly quick processors, we are given increasingly cored processors. Whereas it used to take just one running instance of Access 2000 to bring your CPU usage meter to 100%, it now takes two, four or possibly 128.
Once upon a time, all one needed to know about multi-tasking code was how to hang a few lines of badly-written (I speak for myself) assembly language off the timer interrupt. Those were the days, my friend, we thought they'd carry on; yet here I am giving you a whistle-stop tour through the baffling mechanisms designed to help you envisage and write para-multi-threaded applications.
Let us begin with some ancient history.
Co- not Sub-
The great Donald Knuth described the coroutine, a mechanism for writing single-tasked multi-tasking that allowed any programmer to cope with any situation, merely by thinking of everything at once.
Although it has never really taken off as a popular programming construct, it has been very influential, in particular pioneering the important adjective 'lightweight' (subroutines are a lightweight specialisation of coroutines). Nowadays, of course, 'lightweight' is used as a synonym for 'good' throughout comp. sci., yet it still retains a special affinity for the parallel and pseudo-parallel arts.
A 'thread', abbreviating 'thread of execution', is a lightweight version of the heavier 'process', abbreviating 'process of execution' (as in the phrase 'during the process of execution, the program abruptly died'). Threads save all the tedious mucking about creating state and context demanded by processes, by simply enabling multiple threads to cavort together in the same address space, and with the same resources, like drowning kittens in a bucket of water. Adding cores to the processor improves the threading model by significantly increasing the amount of water available. (Peace: no actual kittens were drowned in the manufacture of that simile.)
In particular, threads suffer badly from 'race conditions'. The race of despised worker threads is made to do boring, low status, 'background' tasks. Meanwhile, the high privilege 'system' threads get to party with the hardware. It's the same the whole world over...
Three old ladies
In order to overcome race conditions, and perhaps to compensate for taking away our beloved 'goto' away from us, top Dutch comp. sci. genius Edsger Dijkstra invented the 'semaphore'. The semaphore is a data structure that allows friendly communication between the threads and tasks of all nations. There are two kinds: the counting semaphore and later, when it has been compiled, the binary semaphore.
The semaphore helped do away with race conditions, and for a while all was sweetness and synchronicity. But it soon became clear that a brand new peril had been introduced: the deadlock.
Today there are at least four well-known kinds of deadlock breeding in the wild:
- Recursive deadlock, which bloody well happens again and again
- Deadly mutual embrace deadlock, which is much less fun than it sounds, being a kind of inter-task stalemate
- Death-of-process deadlock, where the process that claimed the semaphore dies intestate
- Lady Dedlock, a plaintiff in Jarndyce v. Jarndyce
By way of countering the threat and obtaining a deadlock holiday, it was decided to invent the 'mutex' (or 'mutant' as it is known by posher, system threads).
There is a lot of confusion about the difference between mutexes and semaphores, which frankly I do not see as part of my business to clear up. Instead I will refer you to the conventional explanatory model which is, weirdly, based on the notion of the lockable lavatory (or securable brickhouse, as it is almost known by commoner, worker threads).
The scenario is this: imagine a loo in a restaurant of the dismal kind where you must humiliatingly apply to staff for the key. If there is one lavatory and one key, you have a mutex and a long, fidgety wait. If there are four toilets and four interchangeable keys, you have a counting semaphore. The important thing about a counting semaphore is: it doesn't prevent four threads entering one cubicle together.
This licentious view of synchronisation is disputed by other writers, who say that the difference with mutexes is that, before sitting down, they draw the bolt of ownership across the door.
My own view is: synchronisation primitives will never be understood until somebody goes over their metaphors with gallons of industrial-strength bleach.
Next page: Yet more
1. The behaviour is not observable because the sales team are all well-drilled in how to run a staged demo of the system to a client, and will distract them at the crucial moment by saying "Oh, what's that over there" and pointing behind them, or otherwise distracting or making them blink. By the time the client finally discovers the system isn't thread-safe, the ink will long since have dried on the contract - and THAT's when we hit them for support!
2. Trendy is as trendy does. If we're asking from the perspective of a retro-futurist 70s revival, then clearly the Transputer has sandals, beads, beards, corduroy flairs, and all that Open University zeitgeist. The GPU on the other hand is fatally contaminated with the auroa of hardcore gaming nerds, and so will never be any more trendy than a trainspotter's notebook; it may be full of facts and numbers, but it is essentially dull. And slightly distasteful.
You sir, are a humourless arse
Verity, as usual, an excellent piece, as all of yours have been for the many years that Robert Carnegie has apparently not been reading them.
His loss (along with his sense of humour).
Loved the Erlang bit. That should be given to every first year functional programming student to see how long they take to spot the problem. Those that can't see what's wrong should immediately change to a pure maths course to save the rest of us from their code.
Modula-2 and OccamPi
Unlike C and C++, Modula-2 was supporting Co-routines, Stack-frames, Mutex, and Semaphores -- AS PART OF THE LANGUAGE -- over 25 years ago, without any OS support. I have Z80, x86 16bit and x86 32bit Compilers that produce very nice multitasking code for CP/M, DOS, Win16, OS/2 and Win32. In theory the design was to support Multiple Processors too, but my compilers don't have that.
I played a bit with Occam back in 1984, but it was more of a demo toy then. This is worth a look if you want an OS properly designed for Multicore/multicpu.multithread http://rmox.net/ using OccamPi
Additionally (which Apple tries to solve with Grand Central) it's easier to design for a known number of cores/processors rather than an unknown.
It's a pain when the co-routine when inside the Mutex doesn't flush the toilet before leaving. Or even goes with poor aim without sitting down.