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!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Ravenscar and context switching for Cortex-M4
Date: Fri, 13 Feb 2015 16:25:15 +0000
Organization: A noiseless patient Spider
Message-ID: <ly8ug1lqxg.fsf@pushface.org>
References: <ba36d86a-cfb6-475f-9cec-12f1cbb39087@googlegroups.com>
	<ck4k7iFmom0U1@mid.individual.net> <mbkrbq$v3o$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="4eba6dd55c03f4a8d448cad2a88d67ef";
	logging-data="24033"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/GmKcJxbliDuiaWU2yejwRSK3nUGLX1Y8="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (darwin)
Cancel-Lock: sha1:wOpbFk0xJ6cMmKTnjAWUOgcd6/c=
	sha1:b58Udp4jV5w9QaeBwdTORVKEPjc=
Xref: news.eternal-september.org comp.lang.ada:24959
Date: 2015-02-13T16:25:15+00:00
List-Id: <comp.lang.ada>

"G.B." <bauhaus@futureapps.invalid> writes:

> 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? The profile includes
>
>                    Simple_Barriers,
>                    Max_Entry_Queue_Length => 1,
>                    Max_Protected_Entries => 1,
>                    Max_Task_Entries => 0,
>
> 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.

Not just a rule of thumb!

   Tasks may not have entries
   POs may have zero or one entries
   Only one task may be waiting on a PO's entry

but

   you can have 42 tasks each waiting on 42 different POs' single
   entries (if you have enough RAM :-)

I don't know what would happen in my FreeRTOS-based RTS if I let 2 tasks
try to queue on the same entry ... I'd get Program_Error with "entry
call already queued". The variable called Object.Entry_Queue is in fact
a single pointer.