[self-interest] Merlin and Self

[Michael Latta]

Thanks for more pointers, I will check them out.

On your example below.  In the presence of concurrency I would expect 
the result to be unpredictable.  I do not think that is a bad thing.  
It does make it harder to program, but is not incorrect.  The goal of 
making concurrent programming as easy as sequential programming will be 
quite an achievement.  I look forward to your work on this.  If I head 
in that direction I will let you know.

Michael



On Jun 18, 2004, at 4:29 PM, Jecel Assumpcao Jr wrote:

> On Friday 18 June 2004 14:47, Michael Latta wrote:
>> Did you ever incorporate the concurrency ideas from TinySelf into
>> your Merlin product?  Many of the Merlintec pages are very out of
>> date (the english ones anyway).  What is the current status?
>
> Sorry about the ugly and outdated pages. Unfortunately it will be a
> while before I get around to fixing that.
>
> I am currently finishing a 16 bit implementation of a Self processor
> (see http://www.merlintec.com:8080/Oliver), but that has a very
> traditional parallelism model (lightweight threads).
>
> The 32 (and 36) bit version is still in the design stage and does
> implement task switching in hardware using ideas from TinySelf 1. The
> main difference is that instead of having every single object run in
> parallel with all the rest, they are divided into groups which share a
> single message queue and execution stack. So messages within a group
> are sequential. A very poor and short description can be found in
> http://www.merlintec.com:8080/Software/Parallelism
>
> The main issue is "what is an object't state?" Just the bits in its
> slots? The bits in the slots of object it points to? The bits in the
> parents? We don't want the state to become inconsistent, so we must
> avoid concurrent changes to that state.
>
> Microlingua seems to have combined ideas from Slate and TinySelf to
> solve the problem in a way very similar to what Eiffel (from where I
> originally borrowed the idea) did:
> http://www.whysmalltalk.com/Smalltalk_Solutions/ss2003/pdf/rabb.pdf
>
> Here you lock the receiver and all the arguments before executing a
> method. I don't think that is enough -
>
>       mySubObj counter: mySubObj counter + 1.
>
> Since mySubObj is not the receiver nor an argument, it is not locked. 
> Or
> actually, it is locked for "mySubObj counter", then unlocked and later
> locked again for "mySubObj counter:". Another object might point to it
> and be executing this code at the same time.
>
> A drastic solution is to forbid sharing mySubObj, which is what Eiffel
> did. You had active objects and passive objects. The active ones were
> generally the roots of object trees, while the passive ones were the
> rest. A proper program must avoid having a passive objected pointed to
> by more than one active object. That is hard to enforce.
>
> I hope my solution works better, but haven't really given it much
> thought yet since my focus has been on the 16 bit project. But it is
> still an ugly hack and I would love to see a better idea. It should be
> enough to keep half a dozen processors busy, however.
>
> -- Jecel
>
>
>
> Yahoo! Groups Links
>
>
>
>
>