Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!decvax!genrad!teddy!panda!talcott!harvard!seismo!brl-tgr!tgr!BLARSON%ECLD@usc-ecl.ARPA
From: Bob Larson 
Newsgroups: net.lang.c
Subject: Concurency in C
Message-ID: <6856@brl-tgr.ARPA>
Date: Mon, 31-Dec-84 02:59:50 EST
Article-I.D.: brl-tgr.6856
Posted: Mon Dec 31 02:59:50 1984
Date-Received: Tue, 1-Jan-85 06:02:37 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 34


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 

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