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.