Re: Problem with intertask comm

["Tom De Muer" <tom.demuer@skynet.be>]

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