Lots of concurrency

Andrew C. Greenberg werdna at mucow.com
Mon Oct 29 18:32:22 UTC 2001


On Monday, October 29, 2001, at 12:29  PM, Ken Kahn wrote:

> But the problem here is that every time you write 2 lines of code you 
> have
> to think "OK, do they interact?" and then use comma or semi-colon as
> appropriate. This is a cognitive burden. And the consequences for the 
> two
> kinds of mistakes are very different. If you think they interact and 
> they
> don't, then the code will still run - it is just overdetermined (well,
> actually you might have introduced deadlock). If you think they don't
> interact and they do, then you might have introduced a subtle 
> hard-to-find
> bug.
>
> The solution to this that I prefer is to eliminate the semi-colon and 
> only
> support concurrent composition. And then design the language so the
> consequences of pervasive concurrency are acceptable. I think this 
> works in
> languages in which all shared state is encapsulated in objects, where
> threads and objects are one-to-one, and where all messages are 
> asynchronous.

The difficulty, of course, is that this does not relieve the programmer 
of the cognitive burden to determine whether each pair of lines 
interacts -- indeed, it more harshly punishes the programmer who failed 
to do so by creating bugs where sequencing would not.  Finally, absent 
human interaction with the system specifying orders of sequencing, it is 
unobvious that automatic or arbitrary sequencing would be better or more 
efficient than the programmer's order of presentation.

In other words, merely abandoning composition for automatic concurrency, 
rather than providing facilities for both, may well exacerbate the 
problem.  As noted, I could care less if my mind is a mega-complicates 
neural network modelled upon zigacomputational concurrency, if I myself 
cannot comprehend or write such a system.  I would far prefer using a 
model that I CAN comprehend and CAN test and CAN validate.

The bottom line is this: sequential programming can be verified (proved) 
correct by straight-line Hoare or Dijkstra-style reasoning.  Absent 
simplifying invariants, concurrency without straight-line execution 
requires proof that EVERY ONE of the combinatorial explosion of possible 
executions are correct, or properly sequenced, PLUS an additional proof 
of no deadlock.  Whether or not we attempt to formally validate our 
code, the cerebral effort needs to be made informally.

It is bad enough to try to agonize over the cases of state-change in a 
simple loop (and for beginners, hard enough to comprehend the notion of 
a loop invariant).  Imagine doing this for every line of code!





More information about the Squeak-dev mailing list