Multy-core CPUs

Igor Stasenko siguctua at gmail.com
Wed Oct 24 20:55:10 UTC 2007


On 24/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> On 10/24/07, Igor Stasenko <siguctua at gmail.com> wrote:
> >
> > Aha, now i get it.
>
> Good, I should have just posted some theoritical Smalltalk code to
> begin with, this thread would probably be half as big. :)
>
> >So, your approach is to establish a fence between
> > different processes, so they can't share objects. Or maybe more
> > correct to say, that any callee process can have read-only access to
> > any objects which belongs to caller process?
>
> No, the plan was that since in Smalltalk objects are mutable, I will
> have to pay an extra cost for internal message sends and have the VM
> do a deep copy for the sent objects.
>
> Another alternative would be to introduce an immutable flag on
> references, then the "receiver" gets a reference to the object but
> flagged immutable.  This way might be better, but requires more
> changes.
>
> > Its unclear how you would determine to which process object belongs
> > to? This is at minimum would require an additional slot per object
> > (ok, this is doable easily).
>
> Not needed.  The boundaries are: object creation, object send and
> object receive.  All controlled from the VM or in the library, so I
> just have to guarantee that a mutable object can never sneak out of
> it's process, i.e. a process can never get a mutable reference to an
> object owned by a different process.
>
> > Also, unclear how you would persist state (or results of computation).
> > Since all you can do now is to send a message to process, which will
> > return an object in answer.
>
> No, all message sends are async, fire-and-forget.  You don't get a
> future or anything back.  You can easily build sync messages on top of
> this if you want, but the base system isn't planned to directly
> support it.
>
> > Now, since returned object most probably
> > will belong to callee process you must copy it to caller process. But
> > in real you should care of copying a whole subgraph of objects (since
> > you can return a collection of newly created objects (and they , in
> > own turn can be a collections e.t.c.)- and all belonging to callee
> > process). Then , after you done merging a graph, you can simply wipe
> > all memory which was allocated by callee process. This part is easy.
>
> Ah, if you're talking about the receive call, yes that will get an
> object returned.  My first cut will just be (as mentioned above) a
> deep copy.  Performance will likely drive me to adding immutable
> references, or objects or something.  Or perhaps what you're
> suggestion here.
>
> > Now, the most interesting part: mutating an objects in caller process.
> > Suppose my starting process calls two different processes.
> > And they came to the point, that they are willing to update a state of
> > some object(s) in caller process (to be clear: process A contains
> > object a, it calls processes B and C in parallel, and now B and C
> > wanting to change state of object a).
>
> Can't happen.  There is no shared state.  Ever.  The only thing that's
> shared is the Process' mail box, but that is an internal VM detail,
> not visible to the processes.
>
> (remaining comments snipped since I think they assume shared state
> which does not exist in my plan.  If you have some reason you think I
> can't avoid it let me know because I don't see it so far).
>
No sharing you say? Oh.. don't let me starting on this. How about a
common procedure of creating a new class? Creating or modifying a
method in some class?
Note that these changes propagated globally in current implementation
due to having a single global namespace (SystemDictionary).
How you planning to deal with that without breaking a uniform model of
smalltalk (everything is an object e.t.c)?

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list