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,ab549d7e16193bf7 X-Google-Attributes: gid103376,public From: franke@paxp12.mipool.uni-jena.de (Frank Ecke) Subject: Re: ATC---The Holy Grail of Ada Tasking? Date: 1998/07/10 Message-ID: #1/1 X-Deja-AN: 370214950 References: <35A2C41D.F22CAE9E@aonix.com> Organization: Friedrich-Schiller-University Jena, Germany Newsgroups: comp.lang.ada Date: 1998-07-10T00:00:00+00:00 List-Id: On 8 Jul 1998 21:00:03 -0400, Robert Dewar wrote: > > I must say that referring to the ATC abomination as the holy grail of > Ada tasking seems almost sacriligeous. To me this is one of the worst > features of Ada 95. It introduces significant distributed overhead, > and the burden of making your code abort safe (especially when there > is no way, if you are not using pramga Abort_Defer, a special GNAT > pragma) to conveniently make code abort safe, except encapsulating it > in junk protected records, is FAR too heavy. We have had a few people > try to use ATC extensively, but in most cases they gave up (making > code async abort safe is really a VERY difficult discipline). Unless > you are very careful ATC is asking for non-repeatable troubles in > complex programs. > I agree; ATC is a subtle topic and I did not intend to praise it. Actually, the phrase ``Holy Grail of Ada Tasking'' was meant ironically in the sense of ``if you want to live in bliss with Ada Tasking, don't touch that stuff!'' Sorry for introducing this ambiguity! The point is that I am currently writing a project alfa core in which I am investigating and comparing the concurrency features of Ada, CHILL, and Java. This, however, requires me to scrutinize each and every aspect of concurrency in these languages. Frank