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!aioe.org!.POSTED.DFxaDADwSkn+6wW9Ah21PA.user.gioia.aioe.org!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Scheduling behaviour issue Date: Thu, 23 Apr 2020 11:56:09 +0100 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: DFxaDADwSkn+6wW9Ah21PA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (darwin) X-Notice: Filtered by postfilter v. 0.9.2 Cancel-Lock: sha1:AWJ0bLa05dA4Q+lt0ksaeUm1QpE= Xref: reader01.eternal-september.org comp.lang.ada:58470 Date: 2020-04-23T11:56:09+01:00 List-Id: Niklas Holsti writes: > 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. I see what you mean. Seems like a fragile design under possible priority reassignment. Not obvious why the work couldn't be done in a single task - no problem! > 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". So FreeRTOS behaves in the same way as RTEMS? the RTEMS documentation [1] says part-way through section 5.6 "All tasks with the same priority will execute in FIFO order" (until they themselves do something to alter this, I think; it's complicated). On the other hand, there seems to be a variety of choices, a lot to get ones head round. [1] https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html