[self-interest] Merlin and Self

[Jecel Assumpcao Jr]

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