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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e81fd3a32a1cacd2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.karotte.org!news2.arglkargh.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Arguments for single-mutex-exclusion on protected types (Was: Does Ada tasking profit from multi-core cpus?) Date: Mon, 19 Mar 2007 20:36:26 -0500 Organization: Jacob's private Usenet server Message-ID: References: <5iGLh.26236$PF.18838@attbi_s21> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1174354493 1139 69.95.181.76 (20 Mar 2007 01:34:53 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 20 Mar 2007 01:34:53 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news1.google.com comp.lang.ada:14562 Date: 2007-03-19T20:36:26-05:00 List-Id: "Jeffrey R. Carter" wrote in message news:5iGLh.26236$PF.18838@attbi_s21... > Randy Brukardt wrote: > > > > The problem with ceiling locking is that it depends on boosting the priority > > of tasks. That means its a big problem for longer-running operations (such > > as I/O, which aren't allowed in protected operations for this reason). And > > it's a big problem for reusable libraries, which can't know ahead of time > > what the ceiling ought to be. (Make it too high, and critical tasks could be > > starved by lower-priority ones operating in the library, make it too low and > > tasks aren't even allowed to access the library.) Consider trying to set the > > ceiling for a container library implemented with protected objects. (At > > least we now can do this on the fly; in Ada 95, it was impossible.) > > The PragmARCs use > > protected type Handle > (Ceiling_Priority : System.Any_Priority := System.Default_Priority) > is > pragma Priority (Ceiling_Priority); > > They're Ada 95, and have been compiled with at least 2 different > compilers. The problem is, as you pointed out, the library can't know > what an appropriate priority is. Only the client can know that, and this > allows the client to specify it. > > Is there something wrong with this approach? Nothing serious, but it's less than ideal: (1) It complicates the interface; it makes the client worry about something that they probably don't care about. (2) It doesn't work for a protected interface (no discriminants); (3) It doesn't work as well if the protected object is wrapped in a tagged type, because tagged types can't have defaults on their discriminants - meaning that it always has to be specified. This also applies to any protected object that defines an interface (it can have discriminants, but no defaults, as it is considered tagged). I suspect that most libraries will fall into category (2) or (3) [the latter because of the need for clean-up, or simply that not all operations need to be protected]. In any case, it illustrates the difficulty of defining general-purpose task-safe libraries. There are a lot of gotchas that don't apply to single-tasking code. Randy.