[net.lang.c] Concurency in C

Bob Larson <BLARSON%ECLD@usc-ecl.ARPA> (12/31/84)

This message is just a few random thoughts on adding concurrency to C.
Note that I am not implementing a concurrent C, nor even working on a
C compiler.  I just think it is better to discuss thinks ahead of time,
rather than having situations like strings in Pascal, the Intel 2716
vs. the TI 2716, etc.  (DON'T MENTION BASIC, the Buggy Asinine Sick
Interpreted Crud.)

1)  Where order of expressing evaluation is not specified, concurrent
evaluation should be allowed.  (Without additional locking mechanisms,
in my opinion.)  This will break a few flaky programs, but should not
hurt a well written program.

2) {{ and }} bracket a set of concurrently executed statements, that
may be executed concurrently or sequentially in any order.  The compound
statement thus formed will be considered terminated only when all statements
inside it have been completed.

This does not break any program I know of, and allows both upward and 
downward compatibility.

Additional issues to be discussed:

Locking mechanisms, when, where, and how.

Checking and modifying status of concurrently executing sub-processes.

Does this help/hinder/upset anyone?  Is serious work on a concurrent C
already taking place?

Bob Larson <Blarson@Usc-Ecl.Arpa>

  ... !ucbvax!Blarson@Usc-Ecl      or whatever
-------

smh@mit-eddie.UUCP (Steven M. Haflich) (12/31/84)

In article <6856@brl-tgr.ARPA> Bob Larson <BLARSON%ECLD@usc-ecl.ARPA> writes:

>2) {{ and }} bracket a set of concurrently executed statements, that
>may be executed concurrently or sequentially in any order.  The compound
>statement thus formed will be considered terminated only when all statements
>inside it have been completed.

The {{ ... }} construction can usefully appear in existing C code, for
instance, to localize and economize register allocations:

	/* Clean up once a week. */
	if (Thursday) {
		{	register struct hearth *ph;
			for (ph = fireplaces; *ph; ph++) clean_hearth(ph);
		}
		{	register struct oven *po;
			for (po = ovens; *po; po++) clean_oven(po);
		}
	}

Here the compiler cannot figure out what kind of bracket it has until it
sees the second inner compound statement.  If you intend the
two-character token to be lexigraphic (i.e. `{{' without intervening
whitespace) rather than syntactic, it is less of a problem, but still I
would resist adding any new fuzziness to the boundary between C's lexer
and parser.  We should have learned from "lvalue=-value".

I could suggest `{[' and `]}', since `[' cannot legitimately (I think)
start a statement, and the proper pairing a `]}' sequence with either
separate `{' and `[' or a single `{[' can unambiguously be determined
from the parse stack.  Unfortunately, this punctuation is visually ugly.