Concurrency Proposal

[Levi Pearson]

My fingers are crossed on being able to get the academic sponsorship,
but it looks likely at this point.  And yes, I would enjoy hearing any
comments on technical points.  I don't think anything I've proposed
would preclude getting the currently written E-style high-level
concurrency stuff to work, but I haven't looked at that in-depth yet.

Regarding continuations in the Scheme48 vm and stack-based allocation:
I haven't read through that part of the Scheme48 vm enough to be sure,
but I was reminded of Henry Baker's paper "Cons Should Not Cons its
Arguments -- A Lazy Alloc is a Smart Alloc" in which he talks about a
mechanism for references to data allocated on the stack to cause that
data to be copied to the heap when the stack frame containing the data
is popped.

In this model, *everything* is initially allocated on the stack, which
results in a big efficiency win when most data is ephemeral and there
are no scope-escaping references to them.  Definitely seems like
something worth looking into.  However, it may have consequences to
the multi-stack concurrency model I've proposed.  I'd have to read the
paper more deeply to be sure.


On 3/9/06, Brian Rce <water at tunes.org> wrote:
> I'm jumping the gun a bit here, but Levi is an undergrad student who
> is trying to get academic sponsorship for some Slate work in this
> direction, so he may be able to work on this seriously.
>
> I don't have much to directly comment on except that it'd be a
> benefit to get some discussion on the technical points so that we
> wind up with a good initial design and don't "code ourselves into a
> corner"; concurrent programming support can be a tricky issue in that
> it pervades assumptions about code and what it can do.
>
> Also, there should be a relation kept in mind between this and the E-
> style work that was done before (mainly in src/lib/process.slate and
> src/lib/concurrency.slate), even if the relation is "replace most of
> it", although eventual-sends are a good idea regardless.
>
> I will say that Scheme48 does offer some decent ideas on how to go
> about things portably, and I need to look at its continuation code
> since they use an array-based stack as well.
>
> On Mar 8, 2006, at 8:58 AM, Levi Pearson wrote:
>
> > Here's the design I've been working on for an implementation of low-
> > level concurrency support in the vm.  Please let me know if you see
> > any design flaws or find the description unclear in any aspect.  I
> > hope to contribute to the implementation, but my time for hacking is
> > limited so it'd be nice if others wanted to work on implementing it
> > as well.
> >
> > This provides only the lowest-level of support for preemptive thread
> > switching; lots of userspace code design is left to be done.
>
> --
> -Brian
> http://tunes.org/~water/brice.vcf
>
>
>
>