implementing some of OOSC concurrency ideas [was: Re:secure remote proxies ( was: Re: [ENH] bytecodePrimClass andbytecodePrimEquivalentaremessage sends. Double dispatch #== )]

Stephan Rudlof sr at evolgo.de
Mon Jan 21 10:14:00 UTC 2002


Rob,

Rob Withers wrote:
> 
> Stephan,
> 
> Please excuse me for being so delayed in aswering this email.  Between work
> and getting familiar with VMMaker and SourceForge, I had put this on the
> back-burner.   Sorry about that.

No problem!
My domain has been down since about Thursday, 1/10/02 to today morning, so
I've just gotten your reply.
Fortunately it doesn't seem to be necessary to resubscribe to the ML, but I
think I have to look into an archive for other messages in the offline time.

> At 07:27 PM 1/11/2002, Stephan Rudlof wrote:
> 
> <snip>
> 
> > > >But they are not identical because one is a proxy, the other not: so you
> > > >need methods like #isProxy or similar at least to get this information.
> > >
> > > Since a proxy acts as a surrogate for the real object, clients of a proxy
> > > should have no idea that they are talking to one.  This is a Transparent
> > > Forwarder (papers at ACM).  This should include normal messages, one would
> > > send to an object, like #class, #==, #size and so on.   On the other hand,
> > > we would want some management control, over the proxy.  I think of these as
> > > the location and behavioral aspects of our reference to the object.
> 
> We started this thread as a result of discussions about whether identity
> should be changes in special circumstances.  If we have two proxies, P1
> forwards from machine L to B then to R, and P2 forwards from machine L to C
> then to R, are they identical?   Depending on what capabilities you are
> implementing, it may be that you _do_ wnat them to be identical.

There is another level of equalness if we go to distributed programming; at
least from a practical point of view.
Inside one image it means that its computation is very fast, but between
different ones? Imagine comparing a number located onto the moon with a
number on earth, one or both proxied...

Another point why I'm somewhat afraid of changing the semantics of #==.

> > >  Of
> > > course, there could be a proxy control protocol, understandable by the
> > > proxy, but it would be better encapsulated by controlling the proxy through
> > > a Mirror.
> >
> >I like this idea!
> >Different 'views' of the proxy dependent on the functionality needed/wished.
> >And with this idea you don't need language extensions for controlling
> >visibility.
> 
> Well, I don't know.  Not for basic functionality it seems, but there may be
> other reasons to extend the VM and have delegation primitives.

Performance?
If we go distributed the connection seems to be more the bottleneck.
 
<snip>

> >What about implementing some of OOSC concurrency ideas in Smalltalk?
> >
> >In the following I will give a very rough sketch in the spirid of OOSC.

> I would have to say that the strictness of preconditions and postconditions
> makes me nervous.

It needn't!
The crucial point here is the 'precondition interpreted as waiting
condition' semantics for synchronization, you could leave out the other
(postcondition, invariant) ones. And you have to realize synchronization
somehow.

> It seems your last 5 points are roughly the
> follwoing.  They are all interesting steps toward concurrency.  Two things
> I am currently worried about are, firstly, self-sends (delegation
> primitives solve this one)

I don't understand here: if I send a message to a proxy for an object, when
do I have a self send?

> and return values,

Copy or not, where to be located if proxied, etc...

> and secondly, deciding what
> to do when the interspace communication gets wedged, do we fail or retry
> every message send in the system?

Good question. And *how* to fail/retry and *how* to handle these cases...

> 1) disjoint object spaces w/ proxies

Yes. For the proof of the concept inside one image this is necessary. I
think they are automatically disjoint for separated images already.
But dealing with these objects ideally should feel as one object space
everywhere. Ideally: number at the moon...

> 2) message wrappers or instance methods.  Controlled sending
> 3) deadlock free concurrency

Message wrappers: for introducing waiting conditions together with some
separation from the 'normal' code by using existing
(prec/post)condition/invariant stuff.

> 4) each space has it's own Processor

No.
Each space may or may not have more than one Processor: a Processor is
exclusively responsible for computations (by calling methods in the public
interface) on one or more objects: this guarantees not to have different
processors acting on the same object at once, since each object has *its*
processor.
But you could have more than one Processor inside the same object space.
Don't think of cpus here, the Processor concept is abstract and Proxies and
Processors are totally different.

Have I misunderstood the relation from 1) and 4) here?

> 5) Polymorphism/Policied Processors for different operating environments

No. Polymorphism/Policied *Proxies* for different operating environments.


The processor idea is from Meyer's OOSC2, I have roughly read the
corresponding chapter.


Greetings,

Stephan

> 
> cheers,
> Robert
> 

> PS.. am I sending HTML again??!!?!?!  Please let me know.

No :-)

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3



More information about the Squeak-dev mailing list