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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,96fc7f1e397aab8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-02 09:26:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3D739109.4040609@worldnet.att.net> From: Jim Rogers User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ceiling priority and priority inversion References: <9b051957.0209020707.562bdac4@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 02 Sep 2002 16:26:42 GMT NNTP-Posting-Host: 12.86.37.127 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1030984002 12.86.37.127 (Mon, 02 Sep 2002 16:26:42 GMT) NNTP-Posting-Date: Mon, 02 Sep 2002 16:26:42 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:28660 Date: 2002-09-02T16:26:42+00:00 List-Id: Mathias wrote: > I an pretty new with Ada and wonder if someone out there can help me clarify > how the pragma Locking_Policy(Ceiling_Priority) works. > > To prevent priority inversion when multiple tasks simultaneously access a > protected object you should apply the pragma > Locking_Policy(Ceiling_Priority). > > As I interpret the book "Concurrency in Ada" by Burns and Wellings it works > as follows: > The effect of the pragma Locking_Policy(Ceiling_Priority) is that all tasks > accessing subroutines in a protected object execute these with the ceiling > priority. If you omit the pragma Priority in the protected object, the > compiler assigns the ceiling priority of the protected object to the highest > priority defined for the system. > > Let's say for an example that the protected object is a buffer shared > between a number of tasks, among which one is a low priority application > task and another is an interrupt handler. Using Ceiling_Priority will cause > all tasks executing within the protected object do so with interrupt > priority. Doesn't this potentially cause a kind of priority inversion? When > the application task executes within the buffer it preempts all other tasks > in the system, even interrupts. > > Shouldn't it instead work like the following? If a low priority task is > executing within a protected object and a task with a higher priority tries > to gain access this object. Then the low priority task should be raised to > the priority level of the waiting task. But if there is no concurrent access > the low priority task executes with its base priority. Quoting from "Ada as a Second Language": "Under the Ceiling_Locking policy, a Priority pragma in a protected declaration specifies the ceiling priority for protected objects of the corresponding protected type. This priority is established when the protected object is created, and cannot be changed afterward. ... If the Ceiling_Locking policy is in effect and a given protected declaration does not have a Priority pragma, Priority'Last is used as the ceiling priority for that protected type. If an operation of a protected object with a given ceiling priority is called by a task with an active priority higher than that ceiling priority, it is a symptom of a design error, and exception Program_Error is raised. Together, these rules ensure that if a higher priority task calls a protected action of the same protected object (and at least one of the protected operations is not a protected function, so the high-priority task must be kept waiting to ensure mutual exclusion), the protected action is completed with at least the urgency of the task that must be kept waiting until the protected operation is complete." The active priority of a task is set when it starts executing a protected action, and may be changed upon completion of the protected operation. There is no provision for changing the priority of a task during the execution of a protected operation. Your scheme would require such priority changes. It would also be very much more complicated to implement than the current Ada scheme. Protected operations, to be effective and safe, must be fast and atomic. Atomic operations are achieved by ensuring that the protected action is not interrupted by another task. Fast operations are the responsibility of the person implementing the protected action. Jim Rogers