Taking 'Access of single task/protected object

Taking 'Access of single task/protected object

[G.B.]

It seems impossible to take the 'Access (or 'Unchecked_Access)
of a single task object, since it cannot be made aliased.
And, I guess, as it is not of a named type, so that there
is no way to express even an anonymous access type.

This is, I think, the crucial bit of a question (34540199)
asked at stackoverflow. (The example uses some listener pattern
which looks like Java written in Ada, but that's not why I'm
asking.)


   task Single is
      entry Something;
   end Single;

   ...some_context (access_discriminant => Single'Access)...

somefile:  prefix of "Access" attribute must be aliased

So, suppose some_context requires indirect access to a single
task object, i.e., to one of an anonymous task type.
Is there a preferred solution to single-task vs. multiple
references?

Re: Taking 'Access of single task/protected object

[Dmitry A. Kazakov]

On 2016-01-07 17:18, G.B. wrote:
> It seems impossible to take the 'Access (or 'Unchecked_Access)
> of a single task object, since it cannot be made aliased.
> And, I guess, as it is not of a named type, so that there
> is no way to express even an anonymous access type.
>
> This is, I think, the crucial bit of a question (34540199)
> asked at stackoverflow. (The example uses some listener pattern
> which looks like Java written in Ada, but that's not why I'm
> asking.)
>
>    task Single is
>       entry Something;
>    end Single;
>
>    ...some_context (access_discriminant => Single'Access)...

It does not make sense because you cannot declare a discriminant without 
mentioning the task type. Therefore it cannot be anonymous.

[ I leave aside the question if anonymous task/protected object types 
should be allowed:

    type T (Reference : access task is entry Something; end) is ...

Ada's degradation has not reached this low, yet? ]

> So, suppose some_context requires indirect access to a single
> task object, i.e., to one of an anonymous task type.
 > Is there a preferred solution to single-task vs. multiple
 > references?

    task type Single is
       entry Something;
    end Single;
    ...
    Object : aliased Single;
    ...
    type T (Reference : not null access Single) is ...

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

Re: Taking 'Access of single task/protected object

[Jeffrey R. Carter]

On 01/07/2016 09:18 AM, G.B. wrote:
> It seems impossible to take the 'Access (or 'Unchecked_Access)
> of a single task object, since it cannot be made aliased.
> And, I guess, as it is not of a named type, so that there
> is no way to express even an anonymous access type.
> 
>   task Single is
>      entry Something;
>   end Single;
> 
>   ...some_context (access_discriminant => Single'Access)...

I don't see how you could declare the discriminant, since it requires an access
definition, which requires a designated subtype.

Suppose you could do this somehow. Then every object of the type with the
discriminant would point to the same task. So there would be no need for the
discriminant, since the operations of the type could simply call the entries of
the task directly.

Presumably the desire is to have multiple single tasks, all with an entry
Something, so that the operations of the type can call different tasks. In this
situation, there would be a finite set of known single tasks, so the type could
hold the task ID of the appropriate task, and operations could select the task
to call based on the ID.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: Taking 'Access of single task/protected object

[J-P. Rosen]

Le 07/01/2016 19:16, Jeffrey R. Carter a écrit :
> Presumably the desire is to have multiple single tasks, all with an entry
> Something, so that the operations of the type can call different tasks. In this
> situation, there would be a finite set of known single tasks, so the type could
> hold the task ID of the appropriate task, and operations could select the task
> to call based on the ID.
This can be achieved by having all the single task inherit an interface.

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

Re: Taking 'Access of single task/protected object

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:n6m9s5$gs7$1@dont-email.me...
...
> Presumably the desire is to have multiple single tasks, all with an entry
> Something, so that the operations of the type can call different tasks. In 
> this
> situation, there would be a finite set of known single tasks, so the type 
> could
> hold the task ID of the appropriate task, and operations could select the 
> task
> to call based on the ID.

That's the point of task interfaces: each such task would have the task 
interface as a progenitor. You'd still need to give the task type a name, 
but what's the harm in that? There's no reason to use a single task other 
than convinience, and once you're code gets complex enough, "convinience" 
should be the last of your concerns.

                            Randy.

>Jeff Carter
>"My brain hurts!"

Seems appropriate when talking about task interfaces. ;-)





> -- 
> Jeff Carter
> "My brain hurts!"
> Monty Python's Flying Circus
> 21 

Re: Taking 'Access of single task/protected object

[J-P. Rosen]

Le 08/01/2016 00:52, Randy Brukardt a écrit :
> There's no reason to use a single task other 
> than convinience, and once you're code gets complex enough, "convinience" 
> should be the last of your concerns.

Hmmm.... not really. There can be value in having syntactic guarantee
that a task is really a singleton, i.e. that there cannot be any other
of its kind (for example, if the task is the only thing declared in a
package spec, then there is no issue of concurrent access to global
variables in the package body).

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