From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,XPRIO autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,db6070970f45c3c6,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-10-26 17:06:14 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!uni-erlangen.de!fu-berlin.de!uni-berlin.de!ppp-1-54.cvx4.telinco.NET!not-for-mail
From: "Nick Roberts" <nickroberts@adaos.worldonline.co.uk>
Newsgroups: comp.lang.ada
Subject: Replicative Partitions
Date: Sat, 27 Oct 2001 01:05:15 +0100
Message-ID: <9rctpj$t532j$1@ID-25716.news.dfncis.de>
NNTP-Posting-Host: ppp-1-54.cvx4.telinco.net (212.1.148.54)
X-Trace: fu-berlin.de 1004141172 30575699 212.1.148.54 (16 [25716])
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Xref: archiver1.google.com comp.lang.ada:15290
Date: 2001-10-27T01:05:15+01:00
List-Id: <comp.lang.ada>

I would appreciate views on the following.

Annex E (of the RM95) seems to make the assumption that each partition will
only be in execution solitarily, rather than there being several instances
of one partition executing concurrently. Indeed, it describes things on the
assumption (or at least from the viewpoint) of there being just one
'program' running. The rationale does not add anything to this.

This viewpoint may be sensible for a typical embedded system. However, in a
system (any system?) which supports the dynamic initiation of the execution
of partitions, several instances of one partition executing concurrently
seems to be at least a possibility. Furthermore, it may be very useful, or
even vitally necessary that this is supported.

For one thing, I suggest the wording of the RM95 should be changed (in the
next revision) to explicitly reflect the possibility of the multiple
execution of a partition, which I shall term a "replicative partition". A
rule would be required, I suspect, that a partition is only permitted to be
replicative if it has no shared passive library units nor RCI bodies
assigned to it.

For another, if the Partition_ID attribute only statically identifies a
partition (the best interpretation to my mind), I suggest it would be
extremely useful to have a means of identifying instances of replicative
partitions, and for the next revision to specify this means.

One possibility is a new language-defined package:

   package System.RPC.Replication is

      type Instance_ID is private;

      Null_Instance: constant Instance_ID;

      function "=" (Left, Right: in Instance_ID) return Boolean;
      -- also "<", "<=", ">", and ">=" ?

      function Image (Instance: in Instance_ID) return String;

      -- possibly other operations of Instance_ID?

      function Current_Instance return Instance_ID;

      function Is_Terminated (Instance: in Instance_ID) return Boolean; -- ?
      function Is_Callable (Instance: in Instance_ID) return Boolean; -- ?

   private
      -- implementation defined
   end;

Each executional instance of any partition, regardless of which node in the
network it is executing on, has a unique identifying value, of type
Instance_ID, called its 'instance identifier'. The function Current_Instance
would return the instance identifier of the instance calling it.

In addition, each remote subprogram (declared in a RCI) would have an
attribute Remote_Caller, which would yield the instance identifier of the
calling instance, within the body of that subprogram (and would be illegal
elsewhere).

This would provide the basis for servers to service multiple instances of a
replicative partition separately, and, provided a caller could not 'fake'
its instance identifier to the server it was calling, it would provide the
basis for any security scheme the server wished to impose.

Needless to say, this is (roughly) the scheme I intend to implement for
AdaOS.

I believe the word 'program' in the RM95 is used inconsistently, and that
its use is unnecessary and confusing. It would be better to leave the
informal meaning in 10.2 (2) and remove all other references to the word or
concept of 'program' throughout the remainder of the RM95 (and simply talk
about the execution of partitions instead).

(a) Am I totally getting hold of the wrong end of the stick on this issue
(as I often do ;-) ?

(b) Is this a matter that has been usefully discussed before? On c.l.a?

(c) Would the scheme I propose be worth inclusion in the next revision of
the language, or is it a bit too esoteric (or poorly formed)?

(d) Are there any further points related to this issue of which I should be
aware?

Many thanks,

--
Nick Roberts