comp.lang.ada
 help / color / mirror / Atom feed
From: "Alex R. Mosteo" <devnull@mailinator.com>
Subject: Re: Ada Task Priorities (Windows vs Linux)
Date: Mon, 17 Apr 2006 14:14:14 +0200
Date: 2006-04-17T14:14:14+02:00	[thread overview]
Message-ID: <44438696.4070209@mailinator.com> (raw)
In-Reply-To: <wccfykhj6s0.fsf@shell01.TheWorld.com>

Robert A Duff wrote:
> "AAFellow@hotmail.com" <AAFellow@hotmail.com> writes:
> 
> 
>>Hi,
>>
>>Thanks for the help....
> 
> 
> You're welcome.
> 
> 
>>...I just ran some test code (which I also ran on windows), and it
>>seemed that on Linux the priorities set in the code have absolutely no
>>effect on how the code runs, whereas on windows, the effect is obvious.
>> I'm looking into this now.
> 
> 
> Priorities can be tricky.  You need to understand whether the Systems
> Programming and/or Real Time annexes are in effect, and what the
> policies are.  Read the compiler documentation.  You need to know how
> many CPUs you have.  On some operating systems, you might need to run in
> supervisor mode in order to get strict real-time priorities.

Yep. Some 3.15p windows experiences of mine from the past that may be of 
use to the original poster:

You have more priorities in Gnat than in windows. This means that 
several Ada priorities are mapped to the same windows priority. (This is 
explained in some .ads file, maybe system.ads?). Furthermore, regular 
windows processes can receive priority boosts and aren't strictly FIFO 
scheduled per priority.

Adding the Ceiling_Locking pragma will cause your program to be put in 
the realtime windows class, which gives you six levels of priorities 
which follow more closely the annex D rules (IIRC). For example, no 
priority boosts happen here. Still you must take care of the Ada -> 
windows priority mapping. And since now your program is in the realtime 
class, you can easily hang your windows if you don't take care with your 
tasks. Windows processes in the realtime class have more priority than 
all other processes in the other classes (idle, normal, above_normal, 
again IIRC).

Someone said to me that in windows protected objects didn't honored the 
Ceiling_Locking policy in the sense that a task entering the monitor 
would not have its priority raised to the ceiling, so unexpected 
priority inversions could still occur. I don't tested this, so maybe it 
is fud.



      reply	other threads:[~2006-04-17 12:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-12 15:24 Ada Task Priorities (Windows vs Linux) AAFellow
2006-04-12 17:08 ` Robert A Duff
2006-04-13 21:26   ` AAFellow
2006-04-14  1:16     ` Robert A Duff
2006-04-17 12:14       ` Alex R. Mosteo [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox