Intended use of package Ada.Task_Attributes

Intended use of package Ada.Task_Attributes

[Mark Lorenzen]

Hello,

Regarding the package Ada.Task_Attributes, what is the intended use of
user-defined task attributes? I can find no godd hints in the AARM. Is
it the intention that a user (programmer) can define all sorts of
attributes or is the package of more use to compiler vendors for
implementing implementation-defined task attributes / properties?

What constitutes a "good use" of this package?

Regards,
- Mark Lorenzen

Re: Intended use of package Ada.Task_Attributes

[Dmitry A. Kazakov]

On 05 May 2005 12:50:19 +0200, Mark Lorenzen wrote:

> Regarding the package Ada.Task_Attributes, what is the intended use of
> user-defined task attributes? I can find no godd hints in the AARM. Is
> it the intention that a user (programmer) can define all sorts of
> attributes or is the package of more use to compiler vendors for
> 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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Intended use of package Ada.Task_Attributes

[Jerome Hugues]

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

-- 
Jerome

Re: Intended use of package Ada.Task_Attributes

[Steve]

"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.

Steve
(The Duck)

> -- 
> Jerome 

Re: Intended use of package Ada.Task_Attributes

[Jerome Hugues]

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

Re: Intended use of package Ada.Task_Attributes

[Randy Brukardt]

"Jerome Hugues" <hugues@merlin-lenchanteur.enst.fr> wrote in message
news:slrnd7kf55.5rk.hugues@merlin.enst.fr...
...
> 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.

That's one specific implementation, and it certainly isn't the only way
these could be implemented. Certainly, I wouldn't use the Janus/Ada
implementation in a hard-real-time system (it being essentially what Dmitry
described. But I know of at least one compiler that allocates task
attributes directly in the TCBs. That of course means that the items that
can be task attributes are very limited, but certainly there is no run-time
penalty for having them. Those would be very appropriate for a hard
real-time system.

(Note that this is a perfectly legal implementation of Task_Attributes,
C.7.2(29) allows any limitation at all on the number and size of task
attributes.)

I would suppose that the Ravenscar designers didn't think Task_Attributes
were important enough to mandate a useful (for real-time) implementation.
Some of the restrictions (like this one) in Ravenscar are fairly mysterious.
(But I hasten to point out that real-time isn't my field, so I try not to
second-guess too much in that area...)

                            Randy.