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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c7d533acec91ae16 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Question for the folks who designed Ada95 Date: 1999/04/29 Message-ID: #1/1 X-Deja-AN: 472287596 Sender: bobduff@world.std.com (Robert A Duff) References: <7g2qu4$ca4$1@usenet.rational.com> <7g3b5g$p92$1@nnrp1.dejanews.com> <7g4ae3$hjh2@ftp.kvaerner.com> <7g4gjk$luq@drn.newsguy.com> <7g4rof$42c$1@nnrp1.dejanews.com> <7g4snl$51n$1@nnrp1.dejanews.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-04-29T00:00:00+00:00 List-Id: Robert Dewar writes: > Example of task specification and corresponding body: > > task PROTECTED_ARRAY is > -- INDEX and ITEM are global types > entry READ (N : in INDEX; V : out ITEM); > entry WRITE(N : in INDEX; E : in ITEM); > end; > > task body PROTECTED_ARRAY is > TABLE : array(INDEX) of ITEM := (INDEX => > NULL_ITEM); > begin > loop > select > accept READ (N : in INDEX; V : out ITEM) do > V := TABLE(N); > end READ; > or > accept WRITE(N : in INDEX; E : in ITEM) do > TABLE(N) := E; > end WRITE; > end select; > end loop; > end PROTECTED_ARRAY; > > The intention was most certainly that this be implemented > without a separate thread, using an approach similar to > the protected records of Ada 95, and indeed several Ada > 83 compilers including DEC Ada and Verdix implemented > "passive" tasks in this manner. > > There was a minority thread of opinion in the Ada 95 design > (notably held by Paul Hilfinger and me) that the whole > business of protected records was a mis-step, and that a > better approach would have been to formalize the notion of > a passive task. One of the things that convinced me you and Paul were wrong is to consider the semantics of a conditional entry call, eg: select PROTECTED_ARRAY.WRITE(...); else ... end select; The above task is almost always able to accept a call to Write, but there are small windows of time during which it won't. That semantics seems fishy to me. For the "equivalent" protected object, you can write it so that it will *always* be able to accept a call to Write. Or, in a different example, you can set things up so that the PO is always in one of *two* states (able to accept this entry, or eble to accept that entry), and the transition between states is atomic (that is, callers can't see the PO in the transitory state). So a caller could use a conditional entry call, and know that if the Foo entry isn't available, the Bar entry must have been. That kind of semantics seems cleaner to me. Contrast with a server task, where there's always a window of time while the task loops back to the beginning of the selective accept -- and that window is externally visible. Seems like asking for trouble -- the worst kind of bug, where it only happens once in a blue moon. And some implementations might even optimize away the bug. > I personally do not like the protected types of Ada 95 at > all. Why not? Because they are abstraction impaired. They > have all kinds of restrictions that are from a semantic > point of view nonsense, and which mean that you cannot > compose them. You can for example call a procedure from a > protected procedure, but only if it does not do a > potentially blocking operation. This means that > conceptually every subprogram, since it might be called > from a protected procedure, must reveal in its spec whether > it can do any blocking calls. I agree somewhat with that criticism. Nonetheless, I prefer using protected objects to using rendezvous. > Anyway, bare in mind that the above arguments were fully > presented and explored during the Ada 95 design, and were > rejected soundly, so they must be wrong! I don't see a smily. Minorities (even minorities of one) are often right! - Bob -- Change robert to bob to get my real email address. Sorry.