Related articles |
---|
language syntax for representing concurrency thomasd@cisco.com (Thomas Dejanovic) (1996-12-01) |
Re: language syntax for representing concurrency silver@zko.dec.com (Brian Silver) (1996-12-03) |
Re: language syntax for representing concurrency bm@cs.columbia.edu (Blair MacIntyre) (1996-12-03) |
Re: language syntax for representing concurrency leew@micrologic.com (1996-12-03) |
Re: language syntax for representing concurrency gtr@ast.cam.ac.uk (Guy Rixon) (1996-12-07) |
Re: language syntax for representing concurrency radenska@cs.uiuc.edu (Boyana Norris) (1996-12-07) |
From: | Guy Rixon <gtr@ast.cam.ac.uk> |
Newsgroups: | comp.compilers,comp.programming.threads |
Date: | 7 Dec 1996 22:51:40 -0500 |
Organization: | Royal Greenwich Observatory |
References: | 96-12-016 96-12-033 |
Keywords: | parallel, OOP |
Thomas Dejanovic wrote:
> So does anyone have some neat ideas for representing such a
> concept _clearly_ in an OO way in a language ?
Brian Silver wrote:
> How about:
>
> process = {thread1, thread2, thread3, ..., threadn};
> [other suggestions deleted]
I've done it this way, in C, using C structures to describe each thread.
It works quite well.
One point that I find crucial: in a general us of this technique, one
needs to represent a sequence of interdependent actions. What I ended
up with was thread-control structures with flags that the calling
function was allowed to access directly and a load of provate stuff that
it left alone by convention. Paraphrased in C, it looked like:
t1 = NewThreadObject( .... );
t2 = NewThreadObject( .... );
t3 = NewThreadObject( .... );
do {
t3.ready = (t1.finished && t2.active);
Run( 3, &t1, &t2, &t3 );
} while( !t1.finished || !t2.finished || !t3.finished );
This says "define three parallel operations t1..t3; run t1 and t2 in
parallel immediately, and run t3 when t1 has completed and t2 has got
going." (Run() is written to read and update the flags .ready, .active
and .finished, and to return to its caller each time it changes a flag.)
This scheme scales well to the level of ~20 dissimilar operations going
on at once. After that, the conditional statements in the loops get a
bit cumbersome. Most of the code is moved away from the action-sequence
loop and the parallelism can be expressed in about as many lines as
there are threads, or less if there are very few interdependencies.
--
Guy Rixon, gtr@ast.cam.ac.uk
Software Engineering Group, Tel: +44-1223-374000
Royal Greenwich Observatory Fax: +44-1223-374700
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.