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 Dewar Subject: Re: Question for the folks who designed Ada95 Date: 1999/04/27 Message-ID: <7g4snl$51n$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 471527472 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> X-Http-Proxy: 1.0 x14.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Tue Apr 27 17:39:02 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-04-27T00:00:00+00:00 List-Id: In article <7g4rof$42c$1@nnrp1.dejanews.com>, dennison@telepath.com wrote: I quite realize that Ted's post was intended to be jokes and I appreciate it as that, but one interesting serious issue is raised. > Why do we call tasks "task" when they are really threads? > That's confusing. In fact the idea of the original design was that task is a much higher level concept, and that whether a given task is implemented as a thread is an implementation detail. Most certainly the expectation was that some tasks would not be threads at all. Consider this example from the Ada 83 RM: 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. The objection to this was not so much technical as conceptual. I remember one person at a RTWG meeting saying "I don't care what you say, a task is a thread, and nothing you can say will make me change that opinion". Given this unshakable view of what a task is, then you can see that the notion of abstraction inversion (it is silly to implement locks in terms of threads) is a strong argument. 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. What happens in practice is that people ignore this, and either through illicit knowledge of what is in bodies, or through shear luck, they avoid blocking calls. A much worse outcome -- very common in practice -- is that people DO blocking calls, and they work just fine, because the protected records are implemented with general locks. FOr most implementations the restrictions against potentially blocking operations are totally unnecessary. Indeed these restrictions are only there to serve the needs of high efficiency bare board implementations, and often have little relevance to implementations over operating systems. 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! Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own