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 LarsonNewsgroups: 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 -------