Problem with intertask comm

Problem with intertask comm

[Tom De Muer]

Hi,

I'm doing the same assignment as Pieter Thysebaert who posted a message some
days ago but I came across another problem:

"The prefix to 'ACCESS shall not be statically deeper than that of the
expected type, Continuing"

The problem is located between **:

-- begin code
declare
 monitor_data_a  : aliased Monitor_Data := (Patient => 1);
 monitor_machine_a  : aliased MonitorTask(info_for_monitor =>
monitor_data_a'Access);

** ** patient_data_a : aliased Patient_Data := (id => 1, my_monitor =>
monitor_machine_a'access); ** **
 patient_a   : PatientTask(info_for_patient => patient_data_a'access);
 begin
null;
end;
-- end code

What am I doing wrong here?  Is the monitor_machine_a'access not available
yet?  I thought that was the problem so I declared the patient_data_a &
patient_a in a subblock but same problem there.

Any help appreciated,
Tom De Muer

Re: Problem with intertask comm

[tmoran]

>"The prefix to 'ACCESS shall not be statically deeper than that of the
>expected type, Continuing"
  Consider:
    type Monitor_Data_Pointer is access all Monitor_Data;
    Saved_Away : Monitor_Data pointer;
    procedure p(param: in Monitor_Data_Pointer);
    ...
    declare
      monitor_data_a : aliased Monitor_Data;
      ...
      p(monitor_data_a'access);
      ...
    end;
    Saved_Away.all := Stuff;
and suppose later
    procedure P(Param: in access Monitor_Data) is
    begin
      Saved_Away := Param;
      ...
Stuff will be copied to Saved_Away.all, but Saved_Away.all is
monitor_data_a, which, since we've left the declare block, no
longer exists.  This situation is possible because the prefix
to 'access, namely monitor_data.all, is declared statically
deeper than Saved_Away.  Either monitor_data_a needs to be moved
out of the declare block, to the same level as Saved_Away, or
else "type Monitor_Data_Pointer is access all Monitor_Data;"
needs to be moved down into the declare block, which forces
Saved_Away to be in the declare block and thus safe.

Re: Problem with intertask comm

[Ted Dennison]

In article <3ad5ecf3$0$191$456d72a3@news.skynet.be>, Tom De Muer says...
>I'm doing the same assignment as Pieter Thysebaert who posted a message some
>days ago but I came across another problem:
>
>"The prefix to 'ACCESS shall not be statically deeper than that of the
>expected type, Continuing"
..
>** ** patient_data_a : aliased Patient_Data := (id => 1, my_monitor =>
>monitor_machine_a'access); ** **
> patient_a   : PatientTask(info_for_patient => patient_data_a'access);

The problem is more or less what the error message says it is. However, the
message is written in LRM-eese. I'll try to translate.

Your pointed-to object (the type of monitor_machine_a) is declared inside a
subprogram somewhere. That means that the object will cease to exist when that
subprogram exits. If that happens, any pointers to that object will suddenly be
pointing to unallocated (or worse, allocated for other purposes) memory. That
would clearly be a Bad Thing. The language would like to prevent that from
happening, by creating rules that make that impossible. Restricting what objects
you can copy it into wouldn't work, as that would force the compiler to track
the flow of that value through your code. So instead it restricts the *type* of
objects you can copy that value into. Specificly, you can't copy that value into
an object whose type was declared at a higher scope than the object being
pointed to (and thus might exist when the object itself no longer does).

To get around this, you can do one of the following:

o  Move the declaration of Patient_Data_A into a higher scope.
o  Move the declaration of the type that the Info_For_Patient field uses into a
lower scope.
o  Use 'Unchecked_Access instead of 'Access. Note that if you use this option
you must be able to certify that the object can't possibly ever be used after it
has gone out of scope. Your instructor might still not be happy about it.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Problem with intertask comm

[Tom De Muer]

Hi,

Thanks for the advice...  I'll go for the Unchecked_Access because basically
I'd like to do the following:
  - Create some listener/sender tasks X(1..n)
  - Create some sender/listener tasks Y(1..m)
I want to _dynamically_ assign a listener to a sender.  And if I destroy the
listener/sender tasks before I destroy the sender/listener tasks i'll have a
problem but I don't see how I can do this otherwise.  If I declare for
instance the first class of tasks at a higher scope I can't access the
second class of tasks which are at a lower scope so I could not assign a
listener to a sender... the tasks thus have to be on the same level of scope
to be assigned a reference to each other, or am I wrong?

Regards,
Tom

"Ted Dennison" <dennison@telepath.com> wrote in message
news:tfpB6.4754$FY5.343736@www.newsranger.com...
> In article <3ad5ecf3$0$191$456d72a3@news.skynet.be>, Tom De Muer says...
> >I'm doing the same assignment as Pieter Thysebaert who posted a message
some
> >days ago but I came across another problem:
> >
> >"The prefix to 'ACCESS shall not be statically deeper than that of the
> >expected type, Continuing"
> ..
> >** ** patient_data_a : aliased Patient_Data := (id => 1, my_monitor =>
> >monitor_machine_a'access); ** **
> > patient_a   : PatientTask(info_for_patient => patient_data_a'access);
>
> The problem is more or less what the error message says it is. However,
the
> message is written in LRM-eese. I'll try to translate.
>
> Your pointed-to object (the type of monitor_machine_a) is declared inside
a
> subprogram somewhere. That means that the object will cease to exist when
that
> subprogram exits. If that happens, any pointers to that object will
suddenly be
> pointing to unallocated (or worse, allocated for other purposes) memory.
That
> would clearly be a Bad Thing. The language would like to prevent that from
> happening, by creating rules that make that impossible. Restricting what
objects
> you can copy it into wouldn't work, as that would force the compiler to
track
> the flow of that value through your code. So instead it restricts the
*type* of
> objects you can copy that value into. Specificly, you can't copy that
value into
> an object whose type was declared at a higher scope than the object being
> pointed to (and thus might exist when the object itself no longer does).
>
> To get around this, you can do one of the following:
>
> o  Move the declaration of Patient_Data_A into a higher scope.
> o  Move the declaration of the type that the Info_For_Patient field uses
into a
> lower scope.
> o  Use 'Unchecked_Access instead of 'Access. Note that if you use this
option
> you must be able to certify that the object can't possibly ever be used
after it
> has gone out of scope. Your instructor might still not be happy about it.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Problem with intertask comm

[tmoran]

>listener to a sender... the tasks thus have to be on the same level of scope
>to be assigned a reference to each other, or am I wrong?
  And why can't you put them at the same level?

>> you must be able to certify that the object can't possibly ever be used
As T.E.D. pointed out, requiring an Unchecked_Access is not just the
compiler trying to be difficult.  If you use it you are taking full
responsibility that the program won't try to use a pointer that's
pointing into the weeds.  Don't do it unless you must, and safely can.

Re: Problem with intertask comm

[Ted Dennison]

In article <3ad62703$0$190$456d72a3@news.skynet.be>, Tom De Muer says...
>Thanks for the advice...  I'll go for the Unchecked_Access because basically
>I'd like to do the following:
>  - Create some listener/sender tasks X(1..n)
>  - Create some sender/listener tasks Y(1..m)
>I want to _dynamically_ assign a listener to a sender.  And if I destroy the
>listener/sender tasks before I destroy the sender/listener tasks i'll have a
>problem but I don't see how I can do this otherwise.  If I declare for
>instance the first class of tasks at a higher scope I can't access the
>second class of tasks which are at a lower scope so I could not assign a
>listener to a sender... the tasks thus have to be on the same level of scope
>to be assigned a reference to each other, or am I wrong?

Sort of. Their access value objects have to both be on the same scope as their
access type for 'access to work. They both have to be at the same scope in the
same package, or at some mutually-accessable scope in separate package specs, in
order to know about each other.

As a separate issue, you might want to consider a setup where tasks don't get
destroyed and new ones created later, but they just go into some quiescent state
until they get a new partner. Generally its a Bad Thing to go around destroying
task type objects and creating new ones repeatedly. Ada has to keep some
information about deallocated tasks around so that stuff like 'terminated will
work. That can cause a memory leak. Note that doing this will also solve your
access value scope problem, as no task will ever go out of scope (barring
unhandled exceptions).



---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Problem with intertask comm

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]


"Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
3aDB6.5240> As a separate issue, you might want to consider a setup where
tasks don't get
> [...] Generally its a Bad Thing to go around destroying
> task type objects and creating new ones repeatedly. Ada has to keep some
> information about deallocated tasks around so that stuff like 'terminated
will
> work. That can cause a memory leak [...]
This used to be true in Ada83 due to the so-called (hmm) Rosen's Pathology.
It has been cured in Ada95. It was related to a function returning a local
task object, which is no more allowed.
--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr