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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fb45e48e8dddeabd X-Google-Attributes: gid103376,public X-Google-Thread: ffc1e,fb45e48e8dddeabd X-Google-Attributes: gidffc1e,public From: kaz@ashi.footprints.net (Kaz Kylheku) Subject: Re: Ada Protected Object Tutorial #1 Date: 1999/12/26 Message-ID: #1/1 X-Deja-AN: 565104083 Cache-Post-Path: ashi.FootPrints.net!unknown@localhost References: <839toq$pu$1@bgtnsc03.worldnet.att.net> <385AC716.7E65BD5C@averstar.com> <845pgk$qkf$1@nnrp1.deja.com> X-Complaints-To: abuse@direct.ca X-Trace: brie.direct.ca 946241774 204.239.179.1 (Sun, 26 Dec 1999 12:56:14 PST) Organization: Psycho-Neurotic Institute for The Very, Very Nervous X-Cache: nntpcache 2.3.3b3 (see http://www.nntpcache.org/) User-Agent: slrn/0.9.5.7 (UNIX) Reply-To: kaz@ashi.footprints.net NNTP-Posting-Date: Sun, 26 Dec 1999 12:56:14 PST Newsgroups: comp.programming.threads,comp.lang.ada Date: 1999-12-26T00:00:00+00:00 List-Id: On Sun, 26 Dec 1999 19:20:04 GMT, Robert Dewar wrote: >In article >ji.ac.il>, >> This very interesting article tries to explain why it >> is almost always better to use protected types, and create >> less tasks. It gives detailed examples of many tasking idiom, >> so it is also helpful as a guide to Ada tasking. > > >I disagree with this conclusion. Indeed my view is that it is >almost always better to use an intermediate task than a >protected object unless you specifically need the low level >efficiency that protected objects can provide in some >implementations. > >Why? Because protected objects in Ada have relatively nasty low >level semantics that do not compose properly, because of the That's the sense that I get. For example, earlier in the debate I was told that when the requirements change in certain ways, you have to abandon protected objects. E.g. if you need an object's operation to call into another subsystem which may call back. I buy the argument that it's often better to do with fewer threads. When software has to synchronize with itself internally via a rendezvous mechanism, that is a waste of time. It's more efficient to just let threads go loose into foreign objects and do as much work as possible in a non-blocking manner. Using send/receive/reply discipline for synchronization is a waste of cycles. Though it can lead to software that is easier to debug, no contest there.