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: Thu, 23 Apr 2020 15:57:54 +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 qxYjZ7y2zlNjVBhc7ZQSCw0j2L+X5cmYaA3Ev2RH9sdiyPQvhH Cancel-Lock: sha1:ii3muxBiAfUYrBm23SgWUwYWx8E= 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:58474 Date: 2020-04-23T15:57:54+03:00 List-Id: On 2020-04-23 13:56, Simon Wright wrote: > 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! There are various logical reasons why one may want to divide different SW functions into different tasks -- say, the tasks are triggered sporadically by different input signals but contain several internal suspension points embedded within their respective algorithms. A possible reason to give two different tasks the same priority is that the system supports only a handful of priorities, and luckily there is no reason (from real-time requirements) to assign different priorities to these two tasks, so that distinct priority levels can be saved for other tasks. As I said in a later post, I agree that using static priority assignments to ensure synchronization or mutual exclusion between tasks is fragile, and more robust methods (protected objects) are preferable. On the other hand, I often see posts on e.g. comp.arch.embedded from people who prefer co-operative multi-tasking (or even single-thread programming). They could find it attractive to use such designs based on this Ada feature. Several coding standards (rulebooks) or design standards that I've seen have rules forbidding tasks of equal priority, I assume in order to avoid uncertainties about execution order, including the case under discussion. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .