On 30/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>
> > The idea is simple. Since we have
> > limited set of write operations in object memory we could design a
> > system which prevents a primitive operations (such as primat: put:)
> > from running concurrently on the same object.
> > This means (like in your concept), that each object should have an
> > additional slot identifying a context where it used as receiver.
> > The only write operations which could modify object memory within any
> > method body is write to receiver memory (like setting ivar or indexed
> > var). Other operations (like pushing on stack) is safe, because we'll
> > have separate stack for each execution thread.
> > The message evaluation sequence then can be done as following:
> > - check receiver's assigned context
> > - if it's nil, then assign it to current and start executing method
> > - if its not nil, then schedule method execution to the thread, which
> > owns given context.
>
> It seems to me that you are building event-loops in the VM.  Consider
> anObject that is sent a msg on thread 1, so he is assigned to thread 1 and
> you start processing it with thread 1.  In the meantime, 3 msgs are sent to
> this object on threads 2, 3, and 4.  Each message send is scheduled for
> processing by thread 1, when it becomes available.  There is your
> event-loop.
>

Yes, exactly. I'm still unsure if it really needed for all objects in
system. For instance, the true/false/nil object are just singletons
without any internal state. Thus scheduling them into single thread of
execution can be simply omitted.

> The difference is that you allow objects to be reassigned based on thread
> availability.  Since we have a shared memory, that is as simple as setting
> the new context.  This is similar to ideas I had for redistributing objects
> to different Vats based upon msg send density, which could be monitored, or
> user specification.
>

The other thing which bothers me is a reflection. Should we expose a
properties of native threads at language side (for using/showing them
in debugger)? Or how well new contexts will deal with continuations,
which is used in seaside..
Its hard to give a brief answer for such things.

>
> > when performing a message send in method we deactivate the context,
> > which means that we can set assigned object's context to nil, and set
> > it again when activate context again. Or if we not, then all message
> > sends to given object will be scheduled to same native thread. I don't
> > know what is best - both approaches having own pros and cos.
> > Retaining a context can help us with making all calls to some external
> > library be invoked from single thread.
>
> Indeed.  That would be a Vat.
>
> >
> > Either way we should ensure that there's a single active context at
> > some point of time in system running using same receiver. Also, we can
> > leave most primitives unmodified and be careless about concurrency in
> > these primitives, because by design, there can be only single
> > primitive running in system for particular object at any point of
> > time.
>
> But the primitive may have internal state that can't be shared.
>

I know, but i'm talking about basic primitives which used most
frequently and operating only with object memory. Such primitives
usually don't have any internal state, or using an interpreter state.

All other primitives which have internal state should be reviewed.
And at first stages we could add support for scheduling all these
'old' primitives into single 'main' thread. So they will work as in
current VM not knowing that VM is actually multithreaded.

> >
> > If you can see, such approach gives not much in solving concurrency
> > issues at language side. But that's where i think developers should
> > choose the way. We can provide all what they need
> > (semaphores/promises/futures e.t.c.) in libraries and provide some
> > additional primitives for controlling new aspects of VM.
>
> I could certainly build the language features I am interested in on top of
> such a VM.
>

I'd like to hear more critics about such model :) If it proves to be
viable and much or less easily doable (comparing to other models) then
i could start working on it :)

-- 
Best regards,
Igor Stasenko AKA sig.