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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Scheduling behaviour issue Date: Wed, 22 Apr 2020 21:03:53 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net LF0gg9qdPwIlptiF21qZ4QBYl6jef+8nGdfgm8pfizQN1hTZh3 Cancel-Lock: sha1:2mDpjiYjhmj4qtf7f3pchSeicao= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:58464 Date: 2020-04-22T21:03:53+03:00 List-Id: On 2020-04-22 14:34, Simon Wright wrote: > As some will recall, I've based my Cortex GNAT RTS[1] (for ARM Cortex-M > devices, so far) on FreeRTOS[2]. > > I've now discovered an unfortunate difference between what the ARM > requires at D.2.3(9)[3] and the way FreeRTOS behaves. What we need is > > A task dispatching point occurs for the currently running task of a > processor whenever there is a nonempty ready queue for that > processor with a higher priority than the priority of the running > task. The currently running task is said to be preempted and it is > added at the head of the ready queue for its active priority. > > but FreeRTOS adds the preempted task at the *tail* of its ready queue > ([4], section Prioritized Pre-emptive Scheduling (without Time Slicing), > on page 95 or thereabouts). > > I can see that this will make an application less predictable, but I > don't think it'll make a correct application misbehave. > > I've been having some trouble thinking of a way to demonstrate the > (mis)behaviour! I'm not sure about the definition of a "correct [Ada] application" in this context, but it seems to me that the Ada RM rule means that if several tasks have the same priority, they can assume mutual non-pre-emption, in essence that the running task will not yield to another task within this same-priority set until the running task explicitly blocks or yields. Under that rule, therefore, tasks at the same priority, on the same processor core, can act on shared data without mutual-exclusion protections -- more or less as in a co-operative, non-pre-emptive system -- even if they are pre-empted by higher-priority tasks (which do not share these same data). The tasks in the same-priority set just have to take care not to block or yield while engaged in such actions on shared data. Under RTEMS, if there are higher-priority tasks on that processor core, such actions on shared data would not have this mutual-exclusion property, and the shared data could be messed up. However, I'm not sure if such use of shared data is "correct" per the Ada RM, and if the resulting mess can be called "misbehaviour". > [1] https://github.com/simonjwright/cortex-gnat-rts > [2] https://www.freertos.org > [3] http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-D-2-3.html#p9 > [4] https://bit.ly/2VK7slM -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .