NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/cplus/18285

Text File | 1992-12-22 | 3.9 KB | 91 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!uunet.ca!ohrd!twriter
From: [e-mail] (Timothy Writer)
Subject: Re: Give me safe C++
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Organization: "Ontario Hydro - Research Division"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 21 Dec 92 21:53:21 GMT
Lines: 79

[e-mail] (John MAX Skaller) writes:

>In article <[e-mail]> [e-mail] writes:
>>[e-mail] (John MAX Skaller) writes:
>>
>>>    Next, I feel NO language has addressed the concept
>>>of coroutines (except possibly Simula?). C provides
>>
>>There was (is) a language called Concurrent Euclid which was invented at
>>the University of Toronto some years ago.  In my opinion, it addressed
>>the problem of concurrency (coroutines) quite effectively.

>    In my thinking, processes differ from coroutines.
>First, processes operate concurrently, and so must be synchronised,
>whereas coroutines use a single thread of control that
>swaps back and forward under the control of the coroutines
>themselves (transfer of control is explicit).

It is trivial to simulate your style of coroutines with Euclid processes
using Euclid's conditions and its companion signal and wait statements.
It is rather more difficult to implement Euclid processes using
coroutines as you have described them.

>    The other difference is that coroutines share the environment
>they are instantiated in. If Unix processes cause the stack
>to be duplicated, then coroutines cause the stack to fork.

Euclid processes are not UNIX processes, although you can implement UNIX
processes with Euclid processes.  Euclid processes do share the same
environment and the same address space.  Whether thay share the same
stack or have their own would, I imagine, depend on the particular
implementation.  They are more like a lightweight process mechanism than
a traditional UNIX process, the key difference being that they are
supported at the language level.

>>
>>When the program starts up it immediately creates two processes
>>(coroutines) up and down.  The output might look something like this.
>>
>>1 >2 >3 >2 >3 >4 >3 >2 >1 >0 >-1 >0 >...

>    Random. Coroutines, on the other hand, are completely
>deterministic. They are like subroutines for which the
>caller and callee cannot be distinguished. (Or rather,
>the distinction is relative).

Its random for the simple example I gave but it doesn't have to be.

>>
>>Euclid also provides a means of synchronizing processes using signals
>>and conditions although I don't remember enough to describe it.
>>

>    Coroutine are sometimes used to simulate processes.
>However a proper coroutine facility would have to provide
>the shared memory context and forked local context.
>Of course this can be simulated using objects .. but simulations
>are not the same as syntax. Inventing a syntax for filters
>is not so hard .. but I've never got beyond that. Perhaps
>objects are the only general solution?

I'm not sure I follow you.  I haven't tried to simulate your style of
coroutines but I have tried to simulate Euclid style processes using C++
classes and lightweight processes.  Emulating processes was easy, the
hard part is fitting process synchronization into the object model.  My
point in describing Euclid was simply to point out that there are
languages that provide a proper coroutine facility.  There is no
theoretical reason why C++ could not provide a suitable syntax; however,
I doubt that such a syntax would be adopted into the language standard
in the near future because of the difficuly of implementation esp. on
some platforms.

Tim

--
Tim Writer                 phone:  [phone] ext. 6990
Ontario Hydro Research Division         fax:    [phone]
Toronto, Ontario             e-mail: [e-mail]
CANADA