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 <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Ravenscar - release multiple tasks when an event occurs
Date: Tue, 5 May 2020 20:02:04 +0300
Organization: Tidorum Ltd
Message-ID: <hhdkgdFihcnU1@mid.individual.net>
References: <lyzhapfgdr.fsf@pushface.org> <r8mmrt$hk9$1@dont-email.me>
 <lyeeryfjl3.fsf@pushface.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net eqYHE6qf9kHH8IaKiXzq9Ad0uHWwNeZAkBXRMXs447eMI3ws3g
Cancel-Lock: sha1:Uj2PvzPcTZV4tFeytNRcjCotsAA=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.5.0
In-Reply-To: <lyeeryfjl3.fsf@pushface.org>
Content-Language: en-US
Xref: reader01.eternal-september.org comp.lang.ada:58600
Date: 2020-05-05T20:02:04+03:00
List-Id: <comp.lang.ada>

On 2020-05-05 19:11, Simon Wright wrote:
> "J-P. Rosen" <rosen@adalog.fr> 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!

If an unused task is suspended, it consumes no or very little 
processing. It does reserve stack memory.

If you cannot allow stack memory for all possible tasks (for all 
possible hardware combinations), you can have a pool of tasks, with as 
many tasks as you can support, and allocate tasks dynamically to the 
hardware units that are present. Of course, each task must then have 
enough stack to handle any hardware it is assigned, so you may have to 
use stack memory more conservatively than otherwise.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .