Task activation

Task activation

[tonyg]

I seem to have a problem with task activation

I have a task which I am using to launch other tasks. This task is
activating fine. I have three task pointers in a package spec, when I
want to activate the task I declare a task of the necessary type
inside a procedure and point the access variable to the task. However
it does not seem to get past activation of the task. I cannot see the
reason for this.

Re: Task activation

[tonyg]

On Dec 21, 11:58 am, tonyg <tonytheg...@gmail.com> wrote:
> I seem to have a problem with task activation
>
> I have a task which I am using to launch other tasks. This task is
> activating fine. I have three task pointers in a package spec, when I
> want to activate the task I declare a task of the necessary type
> inside a procedure and point the access variable to the task. However
> it does not seem to get past activation of the task. I cannot see the
> reason for this.

I placed an exception handler to cover this task and it gave the
following error

Exception name: PROGRAM_ERROR
Message: Some tasks have not been elaborated

can someone shed some light on this?

Re: Task activation

[AdaMagica]

On 21 Dez., 13:27, tonyg <tonytheg...@gmail.com> wrote:
> On Dec 21, 11:58 am, tonyg <tonytheg...@gmail.com> wrote:
>
> > I seem to have a problem with task activation
>
> > I have a task which I am using to launch other tasks. This task is
> > activating fine. I have three task pointers in a package spec, when I
> > want to activate the task I declare a task of the necessary type
> > inside a procedure and point the access variable to the task. However
> > it does not seem to get past activation of the task. I cannot see the
> > reason for this.
>
> I placed an exception handler to cover this task and it gave the
> following error
>
> Exception name: PROGRAM_ERROR
> Message: Some tasks have not been elaborated
>
> can someone shed some light on this?

There's way too little information about what you're doing. It seems
you try to access locally defined tasks (inside a procedure) via
global pointers (defined in a package spec). You can't do this. But
this should not even compile. So what are you doing?

Re: Task activation

[Niklas Holsti]

On 11-12-21 13:58 , tonyg wrote:
>
> I seem to have a problem with task activation
>
> I have a task which I am using to launch other tasks. This task is
> activating fine. I have three task pointers in a package spec, when I
> want to activate the task I declare a task of the necessary type
> inside a procedure and point the access variable to the task. However
> it does not seem to get past activation of the task. I cannot see the
> reason for this.

If you declare a task as a local object within a procedure, the 
procedure cannot return until the task is completed. The procedure will 
wait at its "end" for all its local tasks to finish.

If you want to create a task in a procedure in such a way that the task 
continues to exist and run after the procedure returns, you must make 
the procedure allocate a new task object, from the heap, with a "new".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Task activation

[tonyg]

On Dec 21, 12:35 pm, Niklas Holsti <niklas.hol...@tidorum.invalid>
wrote:
> On 11-12-21 13:58 , tonyg wrote:
>
>
>
> > I seem to have a problem with task activation
>
> > I have a task which I am using to launch other tasks. This task is
> > activating fine. I have three task pointers in a package spec, when I
> > want to activate the task I declare a task of the necessary type
> > inside a procedure and point the access variable to the task. However
> > it does not seem to get past activation of the task. I cannot see the
> > reason for this.
>
> If you declare a task as a local object within a procedure, the
> procedure cannot return until the task is completed. The procedure will
> wait at its "end" for all its local tasks to finish.
>
> If you want to create a task in a procedure in such a way that the task
> continues to exist and run after the procedure returns, you must make
> the procedure allocate a new task object, from the heap, with a "new".
>
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

My apologies , the information I supplied was sketchy. My problem (or
challenge :) )
was resolved by using the pragma elaborate_all on my 'with's of the
packages containing
the tasks.

task activation

[Matthew Heaney]

It is my understanding that a task "activates" when you hit the begin 
part of the block in which the task is declared:

procedure Main is
  task O is ...
  task body O is ...;
begin
  <whatever>
end Main;

In this example, task O activates when procedure Main reaches its begin.

Now, suppose we wanted to activate the task earlier than that.  Let's
declare O in a nested package:

procedure Main is
  package P is
    task O is ...;
  end;
  package body P is
    task body O is ...;
  end;
begin
  <whatever>
end;


Does task O activate when

1) the elaboration of nested package P completes (hit the begin part of
P's body); that is, prior to hitting the begin part of Main.  Or,

2) no, the nesting doesn't matter, and O still activates when you hit
the begin part of procedure Main.


Another question: suppose package P is a library level package (and
therefore task O is a library level task).  Does O get activated when

1) you hit the begin part of P's body; that is, prior to hitting the
begin part of Ada main subprogram Main?  Or,

2) no, the library-levelness doesn't matter, and O still is activated
when you hit the begin part of the Ada main.


Thanks,
Matt

--
Time and again the nation's courts have ruled that creationism, as a
religious dogma, cannot be taught in science classes. Now, creationists
are advancing a new tactic: eliminating the teaching of evolution and
other sciences that complement evolution, such as geology, paleontology,
and biological anthropology. By doing so, they are not only endangering
church-state separation but also seriously jeopardizing the science
education of future generations.

http://www.campusfreethought.org/sos/

Re: task activation

[Jean-Pierre Rosen]

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


Matthew Heaney <matthew_heaney@acm.org> a �crit dans le message :
383733d3_1@news1.prserv.net...
> [...]
> Now, suppose we wanted to activate the task earlier than that.  Let's
> declare O in a nested package:
>
> procedure Main is
>   package P is
>     task O is ...;
>   end;
>   package body P is
>     task body O is ...;
>   end;
> begin
>   <whatever>
> end;
>
>
> Does task O activate when
>
> 1) the elaboration of nested package P completes (hit the begin part of
> P's body); that is, prior to hitting the begin part of Main.  Or,
Yes

> 2) no, the nesting doesn't matter, and O still activates when you hit
> the begin part of procedure Main.
>
No.

But you may be confused by the fact that in this case, the ACTIVATOR is P,
but the MASTER is Main.
IOW, the task starts right after you pass the "begin" of P, but Main will
wait for the termination of O.
--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: task activation

[Robert A Duff]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> It is my understanding that a task "activates" when you hit the begin 
> part of the block in which the task is declared:
> 
> procedure Main is
>   task O is ...
>   task body O is ...;
> begin
>   <whatever>
> end Main;
> 
> In this example, task O activates when procedure Main reaches its begin.
> 
> Now, suppose we wanted to activate the task earlier than that.  Let's
> declare O in a nested package:
> 
> procedure Main is
>   package P is
>     task O is ...;
>   end;
>   package body P is
>     task body O is ...;
>   end;
> begin
>   <whatever>
> end;
> 
> 
> Does task O activate when
> 
> 1) the elaboration of nested package P completes (hit the begin part of
> P's body); that is, prior to hitting the begin part of Main.  Or,
> 
> 2) no, the nesting doesn't matter, and O still activates when you hit
> the begin part of procedure Main.

Number 1.

> Another question: suppose package P is a library level package (and
> therefore task O is a library level task).  Does O get activated when
> 
> 1) you hit the begin part of P's body; that is, prior to hitting the
> begin part of Ada main subprogram Main?  Or,
> 
> 2) no, the library-levelness doesn't matter, and O still is activated
> when you hit the begin part of the Ada main.

Number 1 again.  If you have a bunch of such packages, they will get
elaborated in some order that depends on with clauses and various
pragmas -- but when you elaborate the package body, the tasks therein
will be activated.

Another way to control the timing of activation is to put the task in
the heap -- then, an allocator causes the activation, and you can put
that allocator whereever you like.

- Bob

Re: task activation

[Matthew Heaney]

In article <wccg0xyxw9v.fsf@world.std.com> , Robert A Duff 
<bobduff@world.std.com>  wrote:

> Number 1 again.  If you have a bunch of such packages, they will get
> elaborated in some order that depends on with clauses and various
> pragmas -- but when you elaborate the package body, the tasks therein
> will be activated.

OK.  Thanks for this answer.  Now another question.

A few posts ago Robert Dewar made a comment about the problems you can
have if you call a procedure as soon as the task has activated.  For
example:

with P;
package body Q is

  task O;

  task body O is
  begin
    P.Op;
  end;

end Q;

I think what Robert was saying was that you have no guarantee that the
body of P has been elaborated yet.  So if (activated) task O tries to
call an operation provided by P, then you can get Program_Error.  Is
this analysis correct?

What is the solution:

1) Elaborate(all) the packages you call, ie

with P;
pragma Elaborate_All (P);

package body Q is

  task O;

  task body O is
  begin
    P.Op;
  end;

end Q;

Will this work OK?  Or will it constrain the elaboration order
unnecessarily?


2) No, don't elaborate the packages.  Wait to be told (by the Ada main
perhaps, which follows elaboration of all packages) that it's OK to
start:

with P;
package body Q is
  protected Initialization is
    procedure Signal;
    entry Wait;
  private
    OK_To_Start : Boolean := False;
  end;
  ...
  task body O is
  begin
    Initialization.Wait;
    P.Op;
  end;

end Q;


What technique was intended by the language designers to address this
issue?


--
Get the FAQs about evolution and creationism.

<http://www.talkorigins.org/origins/faqs.html>

Re: task activation

[Mats Weber]

Matthew Heaney wrote:

> A few posts ago Robert Dewar made a comment about the problems you can
> have if you call a procedure as soon as the task has activated.  For
> example:
> 
> with P;
> package body Q is
> 
>   task O;
> 
>   task body O is
>   begin
>     P.Op;
>   end;
> 
> end Q;
> 
> I think what Robert was saying was that you have no guarantee that the
> body of P has been elaborated yet.  So if (activated) task O tries to
> call an operation provided by P, then you can get Program_Error.  Is
> this analysis correct?

Yes.

> What is the solution:
> 
> 1) Elaborate(all) the packages you call, ie
> 
> with P;
> pragma Elaborate_All (P);
> 
> package body Q is
> 
>   task O;
> 
>   task body O is
>   begin
>     P.Op;
>   end;
> 
> end Q;
> 
> Will this work OK?  Or will it constrain the elaboration order
> unnecessarily?

It will work OK, and Elaborate_All is just the right pragma, you need no
more, no less.

> 2) No, don't elaborate the packages.  Wait to be told (by the Ada main
> perhaps, which follows elaboration of all packages) that it's OK to
> start:
> 
> with P;
> package body Q is
>   protected Initialization is
>     procedure Signal;
>     entry Wait;
>   private
>     OK_To_Start : Boolean := False;
>   end;
>   ...
>   task body O is
>   begin
>     Initialization.Wait;
>     P.Op;
>   end;
> 
> end Q;

That will work fine too , but you can do it without a protected object:

package P is

   procedure Start;  -- to be called after elaboration.

end P;

with P;
package body Q is

  task O is
    entry Start;
  end O;

  procedure Start is
  begin
     O.Start;
  end;

  task body O is
  begin
    accept Start;
    P.Op;
  end;

end Q;

Re: task activation

[Matthew Heaney]

In article <383A5973.1678A675@mail.com> , Mats Weber <matsw@mail.com>  
wrote:

> That will work fine too , but you can do it without a protected object:

That was deliberate.  I was trying to remove a called-one-time-only
entry from the task, on the assumption that the protected object
approach was more efficient.



--
Time and again the nation's courts have ruled that creationism, as a
religious dogma, cannot be taught in science classes. Now, creationists
are advancing a new tactic: eliminating the teaching of evolution and
other sciences that complement evolution, such as geology, paleontology,
and biological anthropology. By doing so, they are not only endangering
church-state separation but also seriously jeopardizing the science
education of future generations.

http://www.campusfreethought.org/sos/

Re: task activation

[Ehud Lamm]

On Mon, 22 Nov 1999, Robert A Duff wrote:

|Another way to control the timing of activation is to put the task in
|the heap -- then, an allocator causes the activation, and you can put
|that allocator whereever you like.
|

Just a reminder, that though sometimes useful, this is discouraged by the
style guide.

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: task activation

[Simon Wright]

Ehud Lamm <mslamm@mscc.huji.ac.il> writes:

> On Mon, 22 Nov 1999, Robert A Duff wrote:
> 
> |Another way to control the timing of activation is to put the task in
> |the heap -- then, an allocator causes the activation, and you can put
> |that allocator whereever you like.
> 
> Just a reminder, that though sometimes useful, this is discouraged by the
> style guide.

As Robert Dewar has mentioned a few times recently, library level
tasks can give you real headaches at elaboration time, at any rate if
you use GNAT's default elaboration scheme. The style guide may need a
bit of a rethink in this area (at least to lay out the problems and
options).

-- 
Simon Wright                        Work Email: simon.j.wright@gecm.com
Alenia Marconi Systems                         Voice: +44(0)2392-701778
Integrated Systems Division                      FAX: +44(0)2392-701800

Re: task activation

[Robert Dewar]

In article <x7vpuwnll5s.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> As Robert Dewar has mentioned a few times recently, library
> level tasks can give you real headaches at elaboration time,
> at any rate if you use GNAT's default elaboration scheme. The
> style guide may need a bit of a rethink in this area (at least
> to lay out the problems and options).

Not such a headache, one of the following usually works fine

Separate the task type declaration and task object declaration
into separate units.

Suppress elaboration checks in the task body if you know the
body is not executed till after elaboration is complete.

Use the pragma Restrictions to say that no entry calls appear
in elaboraiton code.




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: task activation

[Simon Wright]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Use the pragma Restrictions to say that no entry calls appear
> in elaboraiton code.

I can't make out _which_ Restriction?

Re: task activation

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Suppress elaboration checks in the task body if you know the
> body is not executed till after elaboration is complete.

I don't understand this one.  What effect does this have on the static
elab method?  I thought that if you use the static elab method, you
wouldn't get any checks at all, so what's the point of suppressing them?

- Bob

Re: task activation

[Robert Dewar]

In article <x7vpuwnll5s.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> As Robert Dewar has mentioned a few times recently, library
> level tasks can give you real headaches at elaboration time,
> at any rate if you use GNAT's default elaboration scheme. The
> style guide may need a bit of a rethink in this area (at least
> to lay out the problems and options).

Actually it is not really an issue of GNAT's default static
elaboration scheme. This just alerts you to the real issue,
which is that if you *really* have task bodies executing
all kinds of stuff before elaboration of the program is
complete, you potentially have a mess, which could show up
as non-deterministic program_error exceptions!


Sent via Deja.com http://www.deja.com/
Before you buy.