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!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wns14feed!worldnet.att.net!attbi_s21.POSTED!53ab2750!not-for-mail
From: "Jeffrey R. Carter" <jrcarter@acm.org>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Arguments for single-mutex-exclusion on protected types (Was:
 Does Ada tasking profit from multi-core cpus?)
References: <rgcukvs1j6ck$.1vjj69zzy1h56$.dlg@40tude.net>
 <yfydnaboycG2YHHYnZ2dnUVZ_tadnZ2d@comcast.com> <pKiHh.734$PF.381@attbi_s21>
 <ygey7lxb6tg.fsf_-_@hugsarin.dmusyd.edu> <XZKKh.21401$PF.13827@attbi_s21>
 <wcczm6bss2i.fsf@shell01.TheWorld.com> <eths7k$c9n$1@jacob-sparre.dk>
 <wccmz2azb7j.fsf@shell01.TheWorld.com> <etn0dq$i5n$1@jacob-sparre.dk>
In-Reply-To: <etn0dq$i5n$1@jacob-sparre.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <5iGLh.26236$PF.18838@attbi_s21>
NNTP-Posting-Host: 12.201.97.213
X-Complaints-To: abuse@mchsi.com
X-Trace: attbi_s21 1174352129 12.201.97.213 (Tue, 20 Mar 2007 00:55:29 GMT)
NNTP-Posting-Date: Tue, 20 Mar 2007 00:55:29 GMT
Organization: AT&T ASP.att.net
Date: Tue, 20 Mar 2007 00:55:29 GMT
Xref: g2news1.google.com comp.lang.ada:14561
Date: 2007-03-20T00:55:29+00:00
List-Id: <comp.lang.ada>

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?

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12