Lambda the Ultimate

inactiveTopic Concurrency
started 8/5/2000; 11:07:34 AM - last post 8/6/2000; 4:49:33 AM
andrew cooke - Concurrency  blueArrow
8/5/2000; 11:07:34 AM (reads: 830, responses: 1)
Concurrency

HTPP have started dissing threads the same week that a conference was announced to help concurrency "mature into a core engineering discipline".

Mainstream OS thread support may be pretty poor ("both systems grew erratic as the number of executing CPU intensive threads grew larger than the number of processors"), but at least one language shows that if threads are useful, the overhead can be negligable.

What needs to change to make threads easier to use? The traditional asynchronous approach (C, Java), using Dijkstra's mutexes and semaphores is clumsy (although decent class libraries help). The concurrency evangelists I mentioned above are pushing a synchronous approach (Occam), based on Hoare's Communicating Sequential Processes (CSP) (it impressed me, when I first learnt about it).

Although I liked the CSP approach when I read the papers, we continue to use the asynchronous style at work. Ada, I believe, uses the synchronous approach - has anyone used it (or Occam)? Are threads still the main source of serious (hard to fix) bugs ? Also, why do OSes seem to have a hard time supporting threads/what other languages support very lightweight threads?
Posted to "" by andrew cooke on 8/5/00; 11:40:42 AM

Ehud Lamm - Re: Concurrency (Ada)  blueArrow
8/6/2000; 4:49:33 AM (reads: 886, responses: 0)
I am quite familar with the Ada approach, since I teach Ada...

First it shouldbe noted that Ada (this Ada95, the current version) supports not just "tasks" - which are the Ada facility for concurrency, and communicate via rendezvous - but also "protected objects" which are passive data structures which are guarded from concurrent access. These support relatively cheap semaphores and semaphore-like capabilites.

I find it takes a bit of time to "get the idea," and to start using tasks correctly. The most common mistake, in my experience, is that people tend to forget that the task itself is sequential, and assume the task can execute more than one request at a time. This is the first step to making a complete mess of the control flow inside the task.

After you graps the way things are working (and it is a "small idea" that can understood in one chunk), things get much easier than using models that require the use of OS routines.

I am not too famliar with other concrrent langauges (aside from ASM/370...) to give a meaningful assessment.

You can take a look at AdaPower to find some Ada code, or I can post here some simple example code, if you wish.

Another good source is the Ada Rationales. The Ada83 Rationale has a good discussion of Ada tasking, and the Ada 95 Rationale explains the reasoning behind the addtion of protected types.