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=-0.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, FREEMAIL_REPLY autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f00f4307a7546bf1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Ada Task Priorities (Windows vs Linux) Date: Mon, 17 Apr 2006 14:14:14 +0200 Message-ID: <44438696.4070209@mailinator.com> References: <1144855455.401847.282300@i40g2000cwc.googlegroups.com> <1144963600.855367.284280@e56g2000cwe.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net pPyBhGR3PETVvuZbLasCHgUUFyQ3BGvSTEhKoYgosPdKHG4mA= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:3846 Date: 2006-04-17T14:14:14+02:00 List-Id: Robert A Duff wrote: > "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.