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.
prev parent 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