Re: Ravenscar and run-time program parameters

[brodax <matteo.bordin@gmail.com>]

On 29 Ago, 11:02, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 29 Aug 2007 00:48:23 -0700, Maciej Sobczak wrote:
> > As I understand, the Ravenscar profile forbids dynamically created
> > tasks - all tasks have to be created at the library level.
>
> I guess you mean no task allocation per new (directly or indirectly). That
> is not equivalent to library level tasks. For example:
>
> procedure Main is
>    task type Worker;
>    type Brigade is array (Positive range <>) of Worker;
>    Workers : Brigade (1..Get_No); -- This is not static
> begin
>    loop
>       ...
>    end loop;
> end Main;
>
> But yes Ravenscar is very limiting for many things. Free cheese is only in
> a mouse trap.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de


Actually you cannot create tasks local to procedures (or other tasks),
but only in the declarative part of a library level package.

The usual approach is declaring all tasks you need and let some of
them suspend on an entry waiting, for example, for an execution mode
change.

If you need to build a Ravenscar compliant system, I would suggest
always thinking in terms of 3 kinds of building blocks: cyclic tasks,
sporadic tasks and entry-less protected objects. Each sporadic task
would suspend on a "private" entry (in the sense it is visible to that
task only), whose barrier is opened by (potentially) several
interrupts or sw invocations (potentially carrying parameters). In
this manner, some Ravenscar constraints (size of entry queue) are
always verified by construction. And the concurrency model is overly
simplified and allows a very precise static timing analysis.

Regards,
Matteo Bordin