Concurrency Proposal

[Brian Rice]

On Mar 9, 2006, at 1:46 PM, Levi Pearson wrote:

> 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.

It just requires a mutexed message queue for inter-process sends, so  
is not a big deal.

> 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.

This is beyond what Scheme48 does, which is really simple: just a  
principled operation that copies and restores stack sections.

Stack allocation and lazy heap-migration is a worthwhile idea, but  
not worth discussing yet.

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060309/a8b76463/PGP.pgp