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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,97ae587931c0f702 X-Google-Attributes: gid103376,public From: polley@netins.net (Jonathan Polley) Subject: Re: Ada Task priorities Date: 1997/01/26 Message-ID: #1/1 X-Deja-AN: 212391310 references: content-type: text/plain; charset=ISO-8859-1 organization: netINS, Inc. mime-version: 1.0 newsgroups: comp.lang.ada Date: 1997-01-26T00:00:00+00:00 List-Id: In article , kmradke@inav.net (Kevin Radke) wrote: > Hello, > > Can one guarantee how tasks at different priority > levels will be executed with respect to eachother? > (Speaking in both ada83 and ada95 terms...) > > I.E. the following scenario: > > task a at the highest priority level > task b at a priority level between the highest and lowest levels > task c at the lowest priority level > > Can one guarantee that if all 3 tasks are eligible for execution > at the same time, that task a will finish it's work before > task b begins to run, and task c will only run after both > tasks a and b finish? (Assuming no tasks rendezvous with > other tasks during this time?) > I suppose even OS calls would make this highly platform dependent. > > The ada83 RM seems to be pretty explicit about requiring "The > highest priority eligible task must be executing at any given > time", but the ada95 RM seems less verbose about this. Even > annex D doesn't seem to require this. (Unless I missed something > obvious, which I probably have...) > > My personal opinion is that using assumptions about priorities like this > is just asking for trouble, but I thought I would get other people's opinions > on this... > > Thanks! > Kevin > > -- > /\/\Under Construction/\/\ kmradke@inav.net Kevin, I have found that (with the Rational compiler at least) if a higher priority task is waiting on an OS event (i.e., waiting on data from a TCP socket), it will starve all lower priority tasks. Because of this, I make sure that all my I/O tasks (for TCP, UDP, and X) are the lowest priority tasks in the system. I have not proven, however, that tasks of the SAME priority will NOT be starved (although they shouldn't). Jonathan Polley polley@netins.net The opinions expressed here are my own, yada yada yada.