Unchecked_Conversion and task pointer.

Unchecked_Conversion and task pointer.

[e.coli]

look at this exemple:
----------------------------------------------------
with Ada.Unchecked_Conversion;
with Ada.Text_Io;

procedure Main is

   task type Cain is
      entry Who_Are_You;
   end Cain;

   task type Abel is
      entry Who_Are_You;
   end Abel;

   type Ptr_Cain is access Cain;
   type Ptr_Abel is access Abel;

   task body Cain is
   begin
      loop
         accept Who_Are_You;
         Ada.Text_Io.Put_Line(Item => "I'm Cain");
      end loop;
   end Cain;


   task body Abel is
   begin
      loop
         accept Who_Are_You;
         Ada.Text_Io.Put_Line(Item => "I'm Abel");
      end loop;
   end Abel;


   function Mess_Up is
   new Ada.Unchecked_Conversion
      (
      Source => Ptr_Cain,
      Target => Ptr_Abel);

   X : Ptr_Cain;
   Y : Ptr_Abel;

begin
   X:= new Cain;
   Y:= new Abel;
   X.Who_Are_You;
   Y.Who_Are_You;
   Y:=Mess_Up(X);
   -- where are your brother?
   X.Who_Are_You;
   Y.Who_Are_You;
end Main;
------------------------------------------------

how work Unchecked_Conversion with task pointer?
the behavior depend by the compiler?

thaks

Re: Unchecked_Conversion and task pointer.

[Randy Brukardt]

"e.coli" <maurizio.ferracini@gmail.com> wrote in message
news:1120751455.846822.141050@z14g2000cwz.googlegroups.com...
> look at this exemple:
...
> how work Unchecked_Conversion with task pointer?
> the behavior depend by the compiler?

The Standard make no requirements that this do anything useful. It says that
the result is implementation-defined (which means that it is supposed to be
documented). One allowed result is for the result to be abnormal, which
would allow essentially anything to happen.

What are trying to do? There might be another way to do it (task ids come to
mind).

                         Randy.

Re: Unchecked_Conversion and task pointer.

[Dmitry A. Kazakov]

On 7 Jul 2005 08:50:55 -0700, e.coli wrote:

> look at this exemple:
> ----------------------------------------------------
> with Ada.Unchecked_Conversion;
> with Ada.Text_Io;
> 
> procedure Main is
> 
>    task type Cain is
>       entry Who_Are_You;
>    end Cain;
> 
>    task type Abel is
>       entry Who_Are_You;
>    end Abel;
> 
>    type Ptr_Cain is access Cain;
>    type Ptr_Abel is access Abel;
> 
>    task body Cain is
>    begin
>       loop
>          accept Who_Are_You;
>          Ada.Text_Io.Put_Line(Item => "I'm Cain");
>       end loop;
>    end Cain;
> 
> 
>    task body Abel is
>    begin
>       loop
>          accept Who_Are_You;
>          Ada.Text_Io.Put_Line(Item => "I'm Abel");
>       end loop;
>    end Abel;
> 
> 
>    function Mess_Up is
>    new Ada.Unchecked_Conversion
>       (
>       Source => Ptr_Cain,
>       Target => Ptr_Abel);
> 
>    X : Ptr_Cain;
>    Y : Ptr_Abel;
> 
> begin
>    X:= new Cain;
>    Y:= new Abel;
>    X.Who_Are_You;
>    Y.Who_Are_You;
>    Y:=Mess_Up(X);
>    -- where are your brother?
>    X.Who_Are_You;
>    Y.Who_Are_You;
> end Main;
> ------------------------------------------------
> 
> how work Unchecked_Conversion with task pointer?

Better not to know... (:-))

> the behavior depend by the compiler?

Task types are not tagged in Ada (alas). So if you are trying to have a
kind of task types hierarchy you should use mix-in. Example:

with Ada.Unchecked_Deallocation;

package Persons is
   type Corpse is abstract tagged null record;
   function Get_Name (Context : Corpse) return String is abstract;

   task type Soul (Context : access Corpse'Class) is
      entry Who_Are_You;
   end Soul;
   type Soul_Ptr is access all Soul;
   procedure Free is new Ada.Unchecked_Deallocation (Soul, Soul_Ptr);

   type Abel is new Corpse with null record;
   function Get_Name (Context : Abel) return String;

   type Cain is new Corpse with null record;
   function Get_Name (Context : Cain) return String;
end Persons;
----------------------
with Ada.Text_IO;

package body Persons is   
   task body Soul is
   begin
      loop
         select
            accept Who_Are_You;
               Ada.Text_IO.Put_Line ("I'm " & Get_Name (Context.all));
         or terminate;
         end select;
      end loop;
   end Soul;
   
   function Get_Name (Context : Abel) return String is
   begin
      return "Abel";
   end Get_Name;

   function Get_Name (Context : Cain) return String is
   begin
      return "Cain";
   end Get_Name;
end Persons;
------------------------
with Persons; use Persons;
procedure Test is
   X : aliased Abel;
   Y : aliased Cain;
   Ptr : Soul_Ptr;
begin
   Ptr := new Soul (X'Unchecked_Access);
   Ptr.Who_Are_You;
   Free (Ptr);
   Ptr := new Soul (Y'Unchecked_Access);
   Ptr.Who_Are_You;
   Free (Ptr);
   delay 1.0; -- Let Text_IO task flush all buffers
end Test;

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

Re: Unchecked_Conversion and task pointer.

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1xuh1gs97pwwg$.1v4w9ruw1n2x$.dlg@40tude.net...
...
> Task types are not tagged in Ada (alas).

Task types that inherit from an interface are tagged in Ada 200Y.

> So if you are trying to have a
> kind of task types hierarchy you should use mix-in.

No, you should definitely use an interface. Other than that you may not be
able to find a compiler that supports them yet.

Note that you can't derive from a task type; those have to be leaves in the
hierarchy.


package Persons is
    type Root_Person is interface;
    procedure Who_an_I (Person : in Root_Person);
    type Access_Person is access Root_Person'Class;
end Persons;

  task type Cain and Persons.Root_Person is
      entry Who_Are_You;
  end Cain;

   task type Abel and Persons.Root_Person is
      entry Who_Are_You;
   end Abel;

   -- The bodies of the tasks remain the same.

   Someone : Access_Person := Abel'Access;

   Someone.Who_am_I; -- Dispatch to the appropriate entry.
   Who_am_I (Someone.all); -- The same call in "normal" notation.


                            Randy;

Re: Unchecked_Conversion and task pointer.

[e.coli]

Randy Brukardt wrote:

> What are trying to do? There might be another way to do it (task ids come to
> mind).


i need it, i want pass a pointer to an istance of a task type with a
generic part to an other task outside the package where the generic
task type is defined.
if exist an other way to do this is wellcome :)

Re: Unchecked_Conversion and task pointer.

[Dmitry A. Kazakov]

On Thu, 7 Jul 2005 16:31:51 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1xuh1gs97pwwg$.1v4w9ruw1n2x$.dlg@40tude.net...
> ...
>> Task types are not tagged in Ada (alas).
> 
> Task types that inherit from an interface are tagged in Ada 200Y.

Yes.

>> So if you are trying to have a
>> kind of task types hierarchy you should use mix-in.
> 
> No, you should definitely use an interface.

It depends. Tasks are still non-tagged in the sense that you cannot have a
"task" interface. In an interface Who_Am_I can only be a *procedure*, which
could be then implemented by an entry. But it should an *entry* from the
beginning if the intent is to have a dispatching entry Who_Am_I called
using, say, timed entry call. In that case mix-in will be the only
workaround.

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

Re: Unchecked_Conversion and task pointer.

[Simon Wright]

"e.coli" <maurizio.ferracini@gmail.com> writes:

> i need it, i want pass a pointer to an istance of a task type with a
> generic part to an other task outside the package where the generic
> task type is defined.
> if exist an other way to do this is wellcome :)

You might consider constraining the task type by access to classwide
type and putting the differing functionality there?

  type Job is abstract tagged private;
  type Job_P is access all Job'Class;

  task type Performer (For_Job : Job_P) is ...

(not compiled!)

Re: Unchecked_Conversion and task pointer.

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:28m5yx3jhzvu$.16u6va8093srl.dlg@40tude.net...
...
> > No, you should definitely use an interface.
>
> It depends. Tasks are still non-tagged in the sense that you cannot have a
> "task" interface.

You can declare a task interface in Ada 200Y:

    type T_Int is task interface;

I probably should have done that in my example.

> In an interface Who_Am_I can only be a *procedure*, which
> could be then implemented by an entry. But it should an *entry* from the
> beginning if the intent is to have a dispatching entry Who_Am_I called
> using, say, timed entry call.

You are allowed to use the primitive procedures of an interface in a timed
entry call, and they will work as an entry in that case. So while the
*syntax* is that of a procedure, they do not lose their entry
characteristics and still act as an entry.

I wasn't (and am still not) convinced that this is the right design, but it
certainly works and has the needed effects. I think there will be some
confusion from a readability standpoint, but otherwise you can do everything
with such a procedure that you can do with an entry (other than requeue it;
no one can figure out how a dispatching requeue could work - it couldn't
have been allowed if dispatching entries existed, either).

> In that case mix-in will be the only workaround.

Not at all. See above.

                    Randy.

Re: Unchecked_Conversion and task pointer.

[Dmitry A. Kazakov]

On Sat, 9 Jul 2005 20:42:33 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:28m5yx3jhzvu$.16u6va8093srl.dlg@40tude.net...
> ...
>>> No, you should definitely use an interface.
>>
>> It depends. Tasks are still non-tagged in the sense that you cannot have a
>> "task" interface.
> 
> You can declare a task interface in Ada 200Y:
> 
>     type T_Int is task interface;
> 
> I probably should have done that in my example.

Can a task interface have entries?

>> In an interface Who_Am_I can only be a *procedure*, which
>> could be then implemented by an entry. But it should an *entry* from the
>> beginning if the intent is to have a dispatching entry Who_Am_I called
>> using, say, timed entry call.
> 
> You are allowed to use the primitive procedures of an interface in a timed
> entry call, and they will work as an entry in that case.

Does it mean that in Ada 200Y any procedure of an interface can be used as
if it were an entry?

> So while the
> *syntax* is that of a procedure, they do not lose their entry
> characteristics and still act as an entry.
>
> I wasn't (and am still not) convinced that this is the right design, but it
> certainly works and has the needed effects. I think there will be some
> confusion from a readability standpoint, but otherwise you can do everything
> with such a procedure that you can do with an entry (other than requeue it;
> no one can figure out how a dispatching requeue could work - it couldn't
> have been allowed if dispatching entries existed, either).

Why? Ignoring misleading prefix notation can be ignored, to have a
dispatching requeue, the target task or protected object of the entry must
be class-wide:

task type A is -- This is not Ada
   entry Foo;
end A;
function Factory (...) return A'Class;

Object : X'Class := Factory (...);
...
   requeue Object.Foo; -- Dispatches to Foo
...

BTW, similarly to class-wide subroutines there could be class-wide entries.
A requeue from a class-wide entry to a "primitive" entry of the same object
would be dispatching:

protected type A is -- This is not Ada
   entry Foo'Class;  -- A class-wide entry
   entry Bar;  -- A "primitive" entry
end A;

>> In that case mix-in will be the only workaround.
> 
> Not at all. See above.

It seems so.

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

Re: Unchecked_Conversion and task pointer.

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:tb8600lfqd2z.1l9etgzsgcls2.dlg@40tude.net...
...
> > You can declare a task interface in Ada 200Y:
> >
> >     type T_Int is task interface;
> >
> > I probably should have done that in my example.
>
> Can a task interface have entries?

No, there are no stand-alone entries. But a procedure can match an entry and
be called as an entry.

> > You are allowed to use the primitive procedures of an interface in a
timed
> > entry call, and they will work as an entry in that case.
>
> Does it mean that in Ada 200Y any procedure of an interface can be used as
> if it were an entry?

Any primitive procedure of an interface, yes. If it is not an entry, it is
treated as if it is immediately open.

...
> > I wasn't (and am still not) convinced that this is the right design, but
it
> > certainly works and has the needed effects. I think there will be some
> > confusion from a readability standpoint, but otherwise you can do
everything
> > with such a procedure that you can do with an entry (other than requeue
it;
> > no one can figure out how a dispatching requeue could work - it couldn't
> > have been allowed if dispatching entries existed, either).
>
> Why? Ignoring misleading prefix notation can be ignored, to have a
> dispatching requeue, the target task or protected object of the entry must
> be class-wide:

Well, you can't ignore the prefix (it determines whether it is an internal
or external requeue). And I believe that there was another problem as well.
(I don't remember what it was, sorry.) It certainly doesn't work with the
"use a procedure like an entry" model, because it would make no sense to
requeue on a procedure.

                      Randy.

Re: Unchecked_Conversion and task pointer.

[Dmitry A. Kazakov]

On Mon, 11 Jul 2005 13:28:42 -0500, Randy Brukardt wrote:

> Well, you can't ignore the prefix (it determines whether it is an internal
> or external requeue).

This must be fixed anyway. There is no safe way to statically determine if
a requeue is internal (in Ada 95 it had a quite nasty consequences, like a
program which legality was dependent on whether at run-time a barrier was
open or not.)

For class-wide objects the idea of protected actions should be refined: let
A extend B. Is a protected action on X of A, the same or a different action
on B(X)? What about B'Class(X), A'Class(X)? Further, for multi-methods, let
both tagged arguments resolve to the same type tag, but different objects.
Will it start two actions?

> It certainly doesn't work with the
> "use a procedure like an entry" model, because it would make no sense to
> requeue on a procedure.

Hmm, if a procedure is like an always open entry, then why not to continue
the current protected action while calling the procedure? The action is
completed with return from the procedure.

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

Re: Unchecked_Conversion and task pointer.

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:29tci5buk8ik.12z8wzs6awbnb.dlg@40tude.net...
> On Mon, 11 Jul 2005 13:28:42 -0500, Randy Brukardt wrote:
>
> > Well, you can't ignore the prefix (it determines whether it is an
internal
> > or external requeue).
>
> This must be fixed anyway. There is no safe way to statically determine if
> a requeue is internal (in Ada 95 it had a quite nasty consequences, like a
> program which legality was dependent on whether at run-time a barrier was
> open or not.)

This is confused. "Legality" is a compile-time concept; there is no such
thing as legality being determined by something happening at runtime.
Perhaps you meant something about whether an exception was raised, but that
doesn't seem any different than an array bounds check.

> For class-wide objects the idea of protected actions should be refined:
let
> A extend B. Is a protected action on X of A, the same or a different
action
> on B(X)? What about B'Class(X), A'Class(X)? Further, for multi-methods,
let
> both tagged arguments resolve to the same type tag, but different objects.
> Will it start two actions?

Ada 200Y doesn't allow extensions of task or protected types, specifically
because the tasking operations don't compose well. You can make a set of
rules, but any that are picked either will violate the expectations of the
base type, or will be too restrictive on the extending type. Moreover,
however that is done will make the locking behavior of programs much harder
to understand. Keeping all of the locking in one place is much better in
terms of being able to analyze the effects. So your question cannot arise,
because B necessarily is an interface, and interfaces have no "protected
actions".

                   Randy.

Re: Unchecked_Conversion and task pointer.

[Dmitry A. Kazakov]

On Tue, 12 Jul 2005 15:30:08 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:29tci5buk8ik.12z8wzs6awbnb.dlg@40tude.net...
>> On Mon, 11 Jul 2005 13:28:42 -0500, Randy Brukardt wrote:
>>
>>> Well, you can't ignore the prefix (it determines whether it is an internal
>>> or external requeue).
>>
>> This must be fixed anyway. There is no safe way to statically determine if
>> a requeue is internal (in Ada 95 it had a quite nasty consequences, like a
>> program which legality was dependent on whether at run-time a barrier was
>> open or not.)
> 
> This is confused. "Legality" is a compile-time concept; there is no such
> thing as legality being determined by something happening at runtime.
> Perhaps you meant something about whether an exception was raised, but that
> doesn't seem any different than an array bounds check.

The problem was, if I remember correctly, that a chain of requeues ending
in the starting point could be a bounded error or not depending on the
state of barriers. I suppose it is still so in Ada 200Y.

>> For class-wide objects the idea of protected actions should be refined: let
>> A extend B. Is a protected action on X of A, the same or a different action
>> on B(X)? What about B'Class(X), A'Class(X)? Further, for multi-methods, let
>> both tagged arguments resolve to the same type tag, but different objects.
>> Will it start two actions?
> 
> Ada 200Y doesn't allow extensions of task or protected types, specifically
> because the tasking operations don't compose well.

Some work will be required, but I cannot see any fundamental reason why
tasks and protected objects should not have classes, as well as any other
types, BTW. There was a proposal for protected objects:

http://www.cs.york.ac.uk/rts/papers/YCS_316_99.html

Task entries as primitive operations is more challenging, of course.

> You can make a set of
> rules, but any that are picked either will violate the expectations of the
> base type, or will be too restrictive on the extending type.

Type extension is not the only mechanism of subtyping.

> Moreover,
> however that is done will make the locking behavior of programs much harder
> to understand. Keeping all of the locking in one place is much better in
> terms of being able to analyze the effects. So your question cannot arise,
> because B necessarily is an interface, and interfaces have no "protected
> actions".

Quite formally: if you can call a procedure as an entry, then either there
are entries with no protected actions or each interface procedure has some
virtual protected action (that locks nothing.)

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