On Peter's "address spaces" problem [djg29]

[David Garfield]

On Thu, 3 Jun 93 14:40:46 +0200, "Peter Mueller" <mueller@sc.ZIB-Berlin.DE> wrote:
> Hi,
> 
> I want to present two points.
...
> 2. I've thinked about a problem, which - in my opinion - covers the area of
>    the compiler designers (see below)
> 
> Ad 2.
> 
> Last night the following problem (and it's possible solution) came into my
> mind. An object is, at least able to have two 'address spaces', namely private
> and public. Variables, or 'objects' within the private space are only visible
> to the object, whereas objects in the public space are also seen to the outer
> world.
> 
> Now consider the following object:
> 
> class example {
>    int i;               // i is private
> 
> public:
>    int j;               // j is public
> 
>    void do_something() {
>       i = 1;            // Change object's private state
>       j = i + 1;        // Change object's public state
>    }
> };
> 

In C++ (the language of your example), these exist, but they are not 
called public and private.  They are called static member variables 
and member variables.  Please use the right notation.  

> Now consider, that 'do_something()' is a service, made available via the
> DIRECTORY SERVICE. Then (I take the term now:) client objects can remotely
> invoke do_something().
> 
> What happens?
> 
> For the client object, the example must change its private state! But this
> must only be seen to the client object! Not to others. On the other hand,
> the change to the public state must be seen to all other clients.
> 
> We can say, the change of the private state is a local change to the state
> seen by a specific client object, whereas a change of the public state is
> a global change seen to all possible client objects.
> 
> Where are the problems?
> 
> The global change leads to a synchronization problem. In each situation we
> have to take care to establish a consistent state. (I think, that's where
> the compilers must give as much as help as they can!)
> 
> The local change makes it necessary to provide a copy of at least the private
> members of an object for each client object! (And therefore we need tools, 
> which similiar to those nice stub-making tools for RPC.)
> 
> Solutions?
> 
> Well, to the local change there is an easy solution. Each client, wanting to 
> use other objects' methods remotely, will create an appropriate instance of
> a server class. This class will inform the remote object, that there is a new
> client. This will lead at the remote object to 'fork' (if you will forgive my
> UNIXness ;-) a private copy, especially for this new client. The private copy 
> consists of 
> 
>    1) The private state as it was created on server startup time. (Each time
>       a new client occurs, it will see the same private state.)
>    2) The public state at this time. (A newly client can see different states
>       than previous ones.)
> 
> At the client side, this will be done within the constructor of the server class
> instance. The destructor call will inform the remote object to discard the
> created client's private view.

I am confused.  It appears that you are trying to say that the client 
owns the data of the class.  This is, IMHO, why we have a kernel.  
When a client wishes to make a new object of a class, a request is 
made to the kernel.  The kernel allocates memory, and invokes the 
constructor, allowing the class driver code access to the object for 
the duration.  This allows the class to set up the clients specific 
data.  The 'shared' data is simply variables local to the classes 
application, that need not have any additional special processing.  

When the application invokes a method of (or "sends a message to" 
depending on your terminology) the object, the class is once again 
given access to the object to do whatever processing needs to be done.  

At no time, IMHO, should the client ever have access to any object 
specific or class specific variables.  If the client needs access to 
data, it should ask for it, not get it itself.

So, all the client ever does have is one number.  This may be an 
object ID or it may be a process specific results of having done an 
open()-like call to gain access to an object (as I suggested once 
before).

> 
> I suggest the following terms for the - perhaps - following discussion:
> 
> connector - This is the object used by a client object to establish a new
>             connection to a remote object. The constructor will inform the 
>             remote object, that there is a new client, whereas the destructor
>             will say, that the client is finished.
> 
> shadow    - This is the (remote) object which is actually seen by a client
>             object after connection. Within this object only the private 
>             (and/or protected (?)) members of the remote object are hold.
>             Public members are still shared through the 'real' remote object.
>             The shadow is created after a connection request by a connector.
> 
> (The connection between client and shadow must provide a merge between the
> valid private and public state. Thus, the shadow 'merges' the local view and
> the global view.)

These terms shoud not be needed.

> 
> Other Problems?
> 
> What's about availability and fault tolerance? Reliability? Garbage collection?

next message...

> 
> Hope, to hear some comments,
> 
> Peter

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com