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!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ravenscar and context switching for Cortex-M4 Date: Fri, 13 Feb 2015 20:08:23 +0200 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net l83+cMo1NdAzXWqzVwinCAh+K+wFPCAcKfqS/JiIhTDnhCPCOP Cancel-Lock: sha1:Gxs5fPSeGhVGEV3gSHx75WvGpNc= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:24961 Date: 2015-02-13T20:08:23+02:00 List-Id: On 15-02-13 14:41 , G.B. wrote: > On 12.02.15 22:28, Niklas Holsti wrote: >> On 15-02-12 22:25 , Patrick Noffke wrote: > >>> According to >>> http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug/the_predefined_profiles.html#ada-restrictions-in-the-ravenscar-profiles, >>> >>> >>> at most one task may be queued on an entry. I take this to mean *on >>> a single entry* and that two tasks may be simultaneously queued on >>> separate entries. Is that correct? >> >> Definitely correct. > > Are you sure this is correct? Yes, as I understood the question. > The profile includes > > Simple_Barriers, > Max_Entry_Queue_Length => 1, > Max_Protected_Entries => 1, > Max_Task_Entries => 0, So? > I thought "essentially no queuing" (hence no more than one > simple entry per object) is a good rule of thumb for Ravenscar > profile based programming. Ravenscar allows at most one entry per protected object; that is what Max_Protected_Entries => 1 means. It is a fixed limitation, not a rule of thumb. Two or more tasks can be simultaneously queued (i.e. blocked) on separate entries, as long as no more than one task is queued on any given entry. These separate entries must be in as many separate protected objects, because each PO can have at most one entry. However, the number of entries per PO is not the essential factor for queuing. In some more permissive tasking profile, there could be multiple entries per PO, and there would still be no queues of blocked tasks if the constraint Max_Entry_Queue_Length => 1 is retained. The OP said: > I have two POs, each with an interrupt handler and an entry. > [snip] > Then I have two tasks, T1 and T2. T1 is blocked on > PO1's entry and T2 is blocked on PO2's entry. Entirely within Ravenscar rules, and the very pattern for handling two different interrupts in a Ravenscar application. AIUI, the Ravenscar rules mean that in a PO with an entry, the entry is basically implemented by: - a Boolean flag, the barrier for the entry - one pointer to the (at most one) task waiting on the closed entry. It would IMO not be a great complication to allow more than one entry per PO; it seems to enough to duplicate the above implementation components for each entry. Still needs no queues of tasks, as long as Max_Entry_Queue_Length => 1. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .