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,fb45e48e8dddeabd X-Google-Attributes: gid103376,public X-Google-Thread: ffc1e,fb45e48e8dddeabd X-Google-Attributes: gidffc1e,public From: Tucker Taft Subject: Re: Ada Protected Object Tutorial #1 Date: 2000/01/02 Message-ID: <386F898C.76FF1DBB@averstar.com>#1/1 X-Deja-AN: 567456365 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: lr1.burl.averstar.com References: <839toq$pu$1@bgtnsc03.worldnet.att.net> <385AC716.7E65BD5C@averstar.com> <845pgk$qkf$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Mime-Version: 1.0 Newsgroups: comp.programming.threads,comp.lang.ada Date: 2000-01-02T00:00:00+00:00 List-Id: 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... One of the critical features of protected objects is the guarantee of bounded priority inversion. In non-real-time systems, this is generally irrelevant. In real-time systems, it can be essential to achieving schedulability. So it is not so much "low level efficiency" as "bounded priority inversion" that protected objects provide, which is a somewhat higher level concern in real-time systems. Perhaps there should be two separate variants of protected types, one that bounds priority inversion, and imposes other restrictions, and one that has no particular restrictions, but makes no guarantees. This would clearly need to be a "spec" property of the protected type, so which variant is wanted would need to be identified somehow in the protected type specification. Historically, we were trying to create a feature to address real-time concerns with rendezvous. The fact that the protected type construct has since been recognized as a potentially useful paradigm for non-real-time synchronization is nice, but may require some liberalization of the language rules to ensure this kind of use is portable across implementations. -Tucker Taft stt@averstar.com AverStar, Inc. Burlington, MA 01803