Spew's Concurrency Extension

Spew's Concurrency Extension

[Benjamin Purcell]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

Hello everybody!

Attached is a paper describing the concurrency extension I wrote.  The
paper can also be found in contrib at /n/contrib/spew/ccc/doc.  There
has already been a small amount of discussion in
irc.freenode.net!#cat-v about it that suggests this may be better
implemented as a preprocessor for C programs something like tbl for
troff or cinap_lenrek's mpc for C. But perhaps I am getting ahead of
myself as we can at least first consider this first attempt.

The whole functionality is contained the file cc/thread.c.  Calls are
made into this file in a few places.  cc/com.c calls into this file to
re-write trees that represent receives on channels and cc.y calls into
this file to construct the other kinds of thread operations.

The entire source can be found at /n/contrib/spew/ccc.  There are some
changes needed to the entry points into libthread.  That is why there
is a new copy of libthread in that directory.  None of the changes are
breaking changes for threaded programs written in the traditional way.
So far I have only implemented the libthread changes for amd64 and
386.

I have also started porting the system to use the concurrency
extensions instead of traditional calls into libthread.  Thus, I have
modified libdraw to return a "typed channel" for receiving mouse and
keyboard events and made some small modifications to some of the
headers to accommodate that as well.  If you are interested in trying
the extension out for yourself then I recommend installing those
libraries and headers.

My current plan is to finish porting the system in order to provide an
iso for further evaluation.  I am about halfway through porting acme
and can probably have the rest of the system done in a week if I have
enough spare time.

To see the extension in action look in /n/contrib/spew/ccc/tests for
functionality tests; in /n/contrib/spew/aplay for a gui audio player;
and in /n/contrib/spew/squint for an implementation of squinting at
power series.

As a final note, anything that does not use the concurrency extensions
will compile byte for byte the same.  The extension essentially
already functions as a preprocessor though because it is implemented
in the compiler it is able to call on the type checking already
provided by KenCC.

I'm sending this out for comments and criticisms. For the non plan 9 users
a copy of everything can be found at github.com/spewspew/ConcurrentC

Happy friday!
spew

[-- Attachment #2: ccc.pdf --]
[-- Type: application/pdf, Size: 45122 bytes --]

Re: [9front] Spew's Concurrency Extension

[kokamoto]

> Hello everybody!
> 
> Attached is a paper describing the concurrency extension I wrote.  

I liked Alef, because it's very clear, and then easy to understand
what is concurrency programming.

Your paper looks like such to me.
Please go ahead, and make it _solid_ to be able to use everywhere
in Plan 9, and included in the standard distribution.

Anyone's comment?

Kenji

Re: [9front] Spew's Concurrency Extension

[cinap_lenrek]

the paper states:

"A channel receive operation val = @chan is rewritten as:
recv(c, c->@out); val = c->@out;"

this is wrong, because channels are a shared resoure, and
you share the intermediate values. so if i have two processes,
doing the recive operation, they'll trash each others
c->@out values. the same applies to send of course.

say, the recv() completes on one process, then scheduler
comes it and runs the other processes recv() overriding
the @out member of the struct.

also note, that recv() can take a nil argument if you do
not need the value, but complete the recv() operation.
you do not need dummy value.

--
cinap