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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c890e6ab3fb2c5fc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-06 02:32:37 PST Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!rutgers!spcuna!solaris.cc.vt.edu!news.alpha.net!uwm.edu!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!epflnews!dinews.epfl.ch!di.epfl.ch!Robb.Nebbe From: Robb.Nebbe@di.epfl.ch (Robb Nebbe) Newsgroups: comp.lang.ada Subject: Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] Date: 6 Feb 1995 10:32:37 GMT Organization: Ecole Polytechnique Federale de Lausanne Sender: nebbe@lglsun3.epfl.ch (Robb Nebbe) Distribution: world Message-ID: <1995Feb6.105842@di.epfl.ch> References: <3f9g1u$j4m@nps.navy.mil> <3go64b$m4u@watnews1.watson.ibm.com> NNTP-Posting-Host: lglsun3.epfl.ch Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: 1995-02-06T10:32:37+00:00 List-Id: I took comp.lang.c++ off the distribution list. (If they want to read interesting posts they can just read comp.lang.ada :-) In article , stt@henning.camb.inmet.com (Tucker Taft) writes: |> |> Here is another analogy. In a normal "dispatching" call, the tag |> of the controlling parameters determines how the "order" given by |> the calling task is carried out, but there is no doubt that something |> will happen. In a call on a protected object, not only is the |> interpretation of the call up to the protected object, but whether |> or not the "order" is carried out at all is up to the protected object. This doesn't seem quite right. A protected object has no say about which calls will be executed. It can enforce that it be in a certain state for a call to take place but this is really no more than a temporal pre-condition. In contrast a task must explicity accept a call on an entry and has complete control over such things as the order in which calls are accepted. A task may also perform actions that are not requested by someone else, a protected object may not. I think this is a case where the syntax better represents the implementation than the semantics. However, I do appreciate that protected subprograms requiring multiple synchronizations are probably not "primitve" and is a good enough justification of why the current syntax was adopted. |> |> Kind of like telling a direct underling to do something, versus |> "asking" a peer to do something ;-). "Sorry I'm busy now" is a legitimate |> answer in the latter case... |> With the cooperative synchronization that exists between tasks this seems right. I see the competetive synchronization involved with protected objects as arbitrating the possesion of the object. Thus multiple peers are competing for the right to tell the protected object what to do. In John's terminology a protected object can never be a subject. Robb Nebbe