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!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: Ravenscar - release multiple tasks when an event occurs Date: Sun, 3 May 2020 17:09:48 +0200 Organization: Adalog Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 3 May 2020 15:09:49 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="6f384b0ad2f96a3abd9f84ef9713df2a"; logging-data="18057"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19KopdABBF/tcfXOYwbHYDS" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cancel-Lock: sha1:wzxbMxPElEIJc1u5KNtdXW1okig= In-Reply-To: Content-Language: fr Xref: reader01.eternal-september.org comp.lang.ada:58565 Date: 2020-05-03T17:09:48+02:00 List-Id: Le 03/05/2020 à 12:43, Simon Wright a écrit : > I have several sensor tasks (in general, 2 at the moment) which will of > course be created and start execution during elaboration. > > I'd like to ensure that they don't actually start reading and reporting > input data until the system is in a state to receive them. > > With the Ravenscar profile it's not obvious how to do this (only one > entry per PO, only one task allowed to queue). I suppose I could just > ignore the inputs until the system's ready to receive them! but has > anyone a scheme which is less clunky? Two cases: 1) You have a fixed, well known number of tasks. Declare as many locks as there are tasks (PO or suspension objects), and have your main program signal each of them when ready. 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). 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... > 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. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr