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

Rob Withers rwithers12 at mediaone.net
Mon Jan 21 05:35:49 UTC 2002


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.

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.

> >  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.

<snip>

> > For all of these we would want control identity (Transparency), security
> > (Opaqueness), messaging (Synchronization),  location (Migration), and
> > mutation (Transaction)
> >

<snip>

>Much of you have written here is *related* to what I have in mind. But the
>focus hasn't been on security, but on to ease distributed programming: some
>(slightly changed) stuff from another - personal - Mail of mine:
>
>Prenote: 2) below is somewhat outdated, since now I think - after some
>discussion with a colleague and after getting a paper (in German) from him,
>not my idea - that method wrappers are the right idea to realize
>preconditions, postconditions, invariants (he has realized it for VASt
>(alpha status, I haven't looked at it so far)). The main problem in 2) below
>is to handle OLD values in postconditions. With his method wrapper mechanism
>(not described here) this is possible.

The RB, in VW has them and I am hoping that Squeak has them as 
well.  MorphicWrappers certainly implements them too.   That is a neat way 
to proxy the behavior of an object, but I believe we want something 
additional to this.  State is always encapsulated and accessed through 
behavior.  If there are optimizations we could do, in a distributed 
environment, my migrating state, then that's great, but only 
optimizations.  What we need to have is an ability to proxy the reference 
to an object.  this would include behavior that mimics the original, but 
deals with the contingencies of having a different reference.

<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 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) and return values, and secondly, deciding what 
to do when the interspace communication gets wedged, do we fail or retry 
every message send in the system?

1) disjoint object spaces w/ proxies
2) message wrappers or instance methods.  Controlled sending
3) deadlock free concurrency
4) each space has it's own Processor
5) Polymorphism/Policied Processors for different operating environments


cheers,
Robert


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




More information about the Squeak-dev mailing list