Re: Intended use of package Ada.Task_Attributes

[Jerome Hugues <hugues@merlin-lenchanteur.enst.fr>]

In article <Lr2dnaaI2Pilj-ffRVn-2Q@comcast.com>, Steve wrote:
> "Jerome Hugues" <hugues@merlin-lenchanteur.enst.fr> wrote in message 
> news:slrnd7k1ct.4m8.hugues@merlin.enst.fr...
>> In article <9g3jomw1nprv$.1oustugm8nxot$.dlg@40tude.net>, Dmitry A. 
>> Kazakov wrote:
>>>> implementing implementation-defined task attributes / properties?
>>>>
>>>> What constitutes a "good use" of this package?
>>>
>>> Basically the task ID is anything you need. You can then create a hash
>>> table to keep pointers to the task specific data global in your system.
>>> This will require dynamic handling of the table and also checking if the
>>> table contains task data and creating them if necessary. Task_Attributes
>>> provides an alternative which might appear more usable in an embedded or
>>> real-time system: statically allocated data, faster data access (no hash
>>> table search needed) etc.
>>
>> Except that it is explicitely forbidden by the Ravenscar profile :(
>>
>> see http://www.adaic.com/standards/rm-amend/html/RM-D-13-1.html
>>
> 
> Did I miss something?
> 
> Who said anything about the requirement of following the Ravenscar profile?
> 
> I thought the Ravenscar profiler was a tool that restricted certain 
> operations that are difficult to prove are safe for safety critical 
> applications.  Which is a small subset of Ada applications.

Sorry, I went a bit fast when reacting to Dmitry argument.

Given that the Ravenscar profile is a subset of Ada, dedicated to
real-time applications, I think it is interesting to think about why
it was discarded.

If you read the implementation notes of GNAT (for GNU/Linux, see
a-tasatt.adb), you'll understand why it is not something one should
allow for any real-time system, unless your tool vendor provide strong
guarantee for your target.

So, I'm not sure it is someone one would consider for any real-time
system, be it Ravenscar-compliant or not.

-- 
Jerome