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.BbH97sg9o6mM6D9Le5/JeQ.user.gioia.aioe.org!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Ravenscar - release multiple tasks when an event occurs Date: Tue, 05 May 2020 17:11:04 +0100 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: BbH97sg9o6mM6D9Le5/JeQ.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) Cancel-Lock: sha1:nX7CqekZJ1tKMMKEeezEFyUiuKE= X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:58595 Date: 2020-05-05T17:11:04+01:00 List-Id: "J-P. Rosen" writes: > Two cases: > 2) you want to easily add new tasks as the system evolves, or perhaps > the number of tasks is read from a configuration file that describes the > interfaces. You can do the same thing, but have a linked list of locks, > and some kind of registration process (which you are likely to need anyway). This is more like it: the C version of the code creates the task when it finds the hardware it needs to deal with, which of course isn't possible in Ravenscar (or Jorvik). Fairly extravagant for an embedded system to have tasks you're never going to use, of course! > Note that the notion of (logical) linked list does not imply dynamic > allocation. F.e., you could have a two state process: a first call where > you provide an access to your own PO, and receive an access to the PO of > the task that registered before you. Then, a second call that blocks on > your own PO. When awaken, each task is in charge of waking up the next > one... Good one .. >> An alternative would be to try for the Jorvik profile, which does >> allow multiple tasks to queue on one entry. >> > Ravenscar is intended for very strict constraints: everything, and > especially all timings and scheduling, must be fully statically > determinable. > > If you don't need such stringent requirements, a more permissive profile > might be more appropriate. I.e. check your requirements first, then > choose a profile. Supporting GNAT_Extended_Ravenscar in Cortex GNAT RTS doesn't look to be too difficult.