tasks as part of record

tasks as part of record

[Stribor40]

http://www.infres.enst.fr/~pautet/Ada95/chap29.htm

Unfortunately this tutorial doesnt show anything....can someone show me how to create few records where each record contain task please. Say if I want record Student...

  type Student is record
       Student_Number  : Positive range 1 .. N;
       Name : String(1..20);
       Count    : Integer ;
       --??tasks
   end record;

and how to create 10 students records....

Re: tasks as part of record

[Simon Wright]

Stribor40 <ikamzic@gmail.com> writes:

> http://www.infres.enst.fr/~pautet/Ada95/chap29.htm
>
> Unfortunately this tutorial doesnt show anything....can someone show
> me how to create few records where each record contain task
> please. Say if I want record Student...
>
>   type Student is record
>        Student_Number  : Positive range 1 .. N;
>        Name : String(1..20);
>        Count    : Integer ;
>        --??tasks
>    end record;
>
> and how to create 10 students records....

   with Ada.Text_IO; use Ada.Text_IO;
   procedure Strib is
      task type T is
         entry Start (Name : String);
      end T;
      type Student is record
         Student_Number : Positive range 1 .. 10;
         Name : String (1 .. 10);
         Count : Integer;
         The_Task : T;
      end record;
      task body T is
      begin
         accept Start (Name : String) do
            Put_Line ("started " & Name);
         end Start;
      end T;
      Students : array (1 .. 10) of Student;
   begin
      for J in Students'Range loop
         Students (J).Student_Number := J;  -- etc
         Students (J).The_Task.Start ("student" & Integer'Image (J));
      end loop;
   end Strib;

Each The_Task may need access to the Student record of which it's a
component. If so, ask again.

Re: tasks as part of record

[Stribor40]

ok how would task now access "Student_Number" component of student record of which is already part. For example how would we inside entry get a hold of Student_Number component...for example here...

....
...

accept Start (Name : String) do
            Put_Line ("started " & Name);
            --I want to do something here with Student_Number--
end Start; 

Re: tasks as part of record

[Jacob Sparre Andersen]

Stribor40 <ikamzic@gmail.com> writes:

> ok how would task now access "Student_Number" component of student
> record of which is already part. For example how would we inside entry
> get a hold of Student_Number component...for example here...

One option would be to make "Student_Number" a variable in the task,
instead of a field in the record.

Another, less safe, option would be to let the task have a discriminant
referencing the containing record.

Greetings,

Jacob
-- 
"Being an absolute ruler today was not as simple as people
 thought.  At least, it was not simple if your ambitions
 included being an absolute ruler tomorrow."

Re: tasks as part of record

[Niklas Holsti]

On 14-10-04 16:11 , Stribor40 wrote:
> ... can someone show me how to create few records where each
> record contain task please. Say if I want record Student...
> 
>   type Student is record
>        Student_Number  : Positive range 1 .. N;
>        Name : String(1..20);
>        Count    : Integer ;
>        --??tasks
>    end record;

Embedding tasks in the data structure is usually not a good idea. For
one thing, tasks are "limited" types, so the Student record type also
becomes "limited", and you can no longer move such record objects from
here to there with assignment statements. For another thing, each task
needs its own stack and control structures, which can consume
significant amounts of memory. Finally, the execution state of a task
can be complex and is private to the task and is not directly visible or
controllable from "outside", as the values of other kinds of
data-structure components are.

Can you explain what you want to accomplish here? What is this task
supposed to do, and why must it be embedded in a Student record?

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

Re: tasks as part of record

[Stribor40]

I though it would be easier if task is componenet of record.   What i would like is that every time task runs i would like to operate on components of student record. 
For example for each student there will be one tasks.  When each tasks run i want it to identify yourself to the screen with student number value. For example

This is task #.       -- where # is student number

Re: tasks as part of record

[Jeffrey Carter]

On 10/05/2014 08:47 PM, Stribor40 wrote:
> I though it would be easier if task is componenet of record.   What i would
> like is that every time task runs i would like to operate on components of
> student record.
> 
> For example for each student there will be one tasks.  When each tasks run i
> want it to identify yourself to the screen with student number value. For
> example

Typically this should be done by having the components in the task, rather than
the task in a record. That is, rather than

task type Actor is
   ...
end Actor;

type R is record
   F1 : ...;
   F2 : ...;
   T  : Actor;
end record;

it's usually better to have

task body Actor is
   F1 : ...;
   F2 : ...;

-- 
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

Re: tasks as part of record

[Niklas Holsti]

On 14-10-06 06:47 , Stribor40 wrote:
> I though it would be easier if task is componenet of record.

*What* would be easier?

Tasks are intended for a specific purpose, which is useful in *some*
applications: to execute separate threads of control concurrently, and
possibly in parallel if the computer has several processors.

As I said before, it is unusual for an application to require a separate
task for each data object (= student record), and such designs are
usually complex and inefficient.

> What i would like is that every time task runs

By default, the conceptual model of Ada tasks is that any and all tasks
can and do run at any time, concurrently and in parallel. If you want
some coordination or synchronisation between tasks, you have to arrange
for that.

> i would like to operate on components of student record. 
> For example for each student there will be one tasks.

Why? Why do you need concurrent / parallel execution of student operations?

> When each tasks run i want it to identify yourself to the screen
> with student number value. For example
> 
> This is task #.       -- where # is student number

If you don't synchronise the tasks in some way, all tasks run
concurrently, and your screen will be a mess of such messages, mixed and
interleaved in any random order. Moreover, using Ada.Text_IO
concurrently from several tasks on the same file object (such as
Standard_Output) is illegal in principle, although it may more or less
"work" in some environments.

I suspect strongly that using tasks at all in your application is
unnecessary, and only complicates the design, which is why I would like
to understand why your application needs concurrency.

By the way, you are posting on the USENET group comp.lang.ada, and most
USENET clients do not show the context of a post automatically. Please
quote, in each post, as much as necessary of the earlier post to which
you are replying, and insert your answers below the sentences to which
they apply. This will make it easier to communicate with you.

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

Re: tasks as part of record

[Dmitry A. Kazakov]

On Mon, 06 Oct 2014 10:18:07 +0300, Niklas Holsti wrote:

> On 14-10-06 06:47 , Stribor40 wrote:
>> I though it would be easier if task is componenet of record.
> 
> *What* would be easier?
> 
> Tasks are intended for a specific purpose, which is useful in *some*
> applications: to execute separate threads of control concurrently, and
> possibly in parallel if the computer has several processors.
> 
> As I said before, it is unusual for an application to require a separate
> task for each data object (= student record), and such designs are
> usually complex and inefficient.

Well, actually it is not so unusual. The software pattern is called "active
object".

You are right it is not easy. However, concerning easier or not, what is
the alternative? Two separate yet coupled objects (task and record)? That
is not necessarily easier. Actually there are three variants all already
mentioned in the thread:

1. Separate record and task one referencing another;
2. Task in a limited record with an access discriminant to;
3. Data hidden in the task, exposed via task's entry.

#1 is a mess;

#2 is active object and has issues with initialization/finalization and
most likely will break under inheritance;

#3 is heavy-weight and coarse because all interfacing go though entries,
entries may have no results, tasks are non-tagged.

But the question is *what*, as you said.

>> i would like to operate on components of student record. 
>> For example for each student there will be one tasks.
> 
> Why? Why do you need concurrent / parallel execution of student operations?

A simulation?
 
> I suspect strongly that using tasks at all in your application is
> unnecessary, and only complicates the design, which is why I would like
> to understand why your application needs concurrency.

Exactly. Before discussing a solution there must be the problem stated.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: tasks as part of record

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Please quote, in each post, as much as necessary of the earlier post
> to which you are replying, and insert your answers below the sentences
> to which they apply.

And please quote *only as much as necessary* of the previous post !!!!
(not referring to you, Stribor40, there are others, particularly those
posting via Google Groups)

Re: tasks as part of record

[Simon Wright]

Stribor40 <ikamzic@gmail.com> writes:

> I though it would be easier if task is componenet of record.  What i
> would like is that every time task runs i would like to operate on
> components of student record.
> For example for each student there will be one tasks.  When each tasks
> run i want it to identify yourself to the screen with student number
> value. For example
>
> This is task #.       -- where # is student number

I'm not saying this is a good idea; limited types can be awkward, and
there will be all sorts of problems with the tasking if you ever want to
delete a student. But, for the record,

   with Ada.Text_IO; use Ada.Text_IO;
   procedure Strib is
      type Student;
      task type T (This : access Student) is
         entry Start (Number : Positive);
      end T;
      type Student is limited record     -- has to be limited
         Student_Number : Positive range 1 .. 10;
         Name : String (1 .. 10);
         Count : Integer;
         The_Task : T (Student'Access);  -- the current Student
      end record;
      task body T is
      begin
         accept Start (Number : Positive) do
            Put_Line ("starting task" & Positive'Image (Number));
            This.Student_Number := Number;
         end Start;
         delay 1.0;
         Put_Line ("this is task" & Positive'Image (This.Student_Number));
      end T;
      Students : array (1 .. 10) of Student;
   begin
      for J in Students'Range loop
         Students (J).The_Task.Start (Number => J);
      end loop;
   end Strib;

Re: tasks as part of record

[G.B.]

On 06.10.14 10:00, Dmitry A. Kazakov wrote:

> 1. Separate record and task one referencing another;
> 2. Task in a limited record with an access discriminant to;
> 3. Data hidden in the task, exposed via task's entry.
>
> #1 is a mess;
>
> #2 is active object and has issues with initialization/finalization and
> most likely will break under inheritance;
>
> #3 is heavy-weight and coarse because all interfacing go though entries,
> entries may have no results, tasks are non-tagged.

#4 could be a pattern as is used in Paraffin, I think:
submit student jobs to some task pool, where "job" describes,
in terms of Ada, a way of executing jobs.

Re: tasks as part of record

[compguy45]

On Monday, October 6, 2014 4:24:02 AM UTC-4, Simon Wright wrote:

> 
> 
> 
> > I though it would be easier if task is componenet of record.  What i
> 
> > would like is that every time task runs i would like to operate on
> 
> > components of student record.
> 
> > For example for each student there will be one tasks.  When each tasks
> 
> > run i want it to identify yourself to the screen with student number
> 
> > value. For example
> 
> >
> 
> > This is task #.       -- where # is student number
> 
> 
> 
> I'm not saying this is a good idea; limited types can be awkward, and
> 
> there will be all sorts of problems with the tasking if you ever want to
> 
> delete a student. But, for the record,
> 
> 
> 
>    with Ada.Text_IO; use Ada.Text_IO;
> 
>    procedure Strib is
> 
>       type Student;
> 
>       task type T (This : access Student) is
> 
>          entry Start (Number : Positive);
> 
>       end T;
> 
>       type Student is limited record     -- has to be limited
> 
>          Student_Number : Positive range 1 .. 10;
> 
>          Name : String (1 .. 10);
> 
>          Count : Integer;
> 
>          The_Task : T (Student'Access);  -- the current Student
> 
>       end record;
> 
>       task body T is
> 
>       begin
> 
>          accept Start (Number : Positive) do
> 
>             Put_Line ("starting task" & Positive'Image (Number));
> 
>             This.Student_Number := Number;
> 
>          end Start;
> 
>          delay 1.0;
> 
>          Put_Line ("this is task" & Positive'Image (This.Student_Number));
> 
>       end T;
> 
>       Students : array (1 .. 10) of Student;
> 
>    begin
> 
>       for J in Students'Range loop
> 
>          Students (J).The_Task.Start (Number => J);
> 
>       end loop;
> 
>    end Strib;

Doesnt this code above give warning "warning: variable "Students" is read but never assigned"??

Re: tasks as part of record

[Simon Wright]

compguy45@gmail.com writes:

> On Monday, October 6, 2014 4:24:02 AM UTC-4, Simon Wright wrote:
>
[..]
>>       type Student is limited record     -- has to be limited
[...]
>>       Students : array (1 .. 10) of Student;
>
> Doesnt this code above give warning "warning: variable "Students" is
> read but never assigned"??

Yes, because it isn't ever assigned, just declared, which means all its
components (including the task component) exist.

It *can't* be assigned, because its components are limited.

So this is an over-enthusiastic warning from GNAT.

Re: tasks as part of record

[compguy45]

is there a way to access say Students(4) componenets while inside start entry?

Re: tasks as part of record

[Shark8]

On 10/13/2014 8:45 AM, compguy45@gmail.com wrote:
>
>
> is there a way to access say Students(4) componenets while inside start entry?
>

Assuming the tasks are declared as:
   task type Student_Task   (This : not null access Student)
   task_type Enrollment_Task(This : not null access Enrollment)
and the records, Student & Enrollment, are as follows:
   type Student(N  : Positive) is limited record
        ID_Number  : Positive range 1 .. N;
        Name       : Unbounded_String;
        Count      : Integer ;
        Student_Op : Student_Task(Student'Access);
    end record;
and
   type Student_Body is arrray(Positive range <>) of Student;
   type Enrollment(Number_of_Students : Positive) is limited record
        Students : Student_Body(1..Number_of_Students);
        Enroll   : Enrollment_Task( Enrollment'Access );
   end record;

THEN
inside the body of Enrollment_Task you could say:
declare
  Quaddius : Student renames This.Students(4);
begin
   -- Do what you will.
end;

Re: tasks as part of record

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> compguy45@gmail.com writes:
>
>> On Monday, October 6, 2014 4:24:02 AM UTC-4, Simon Wright wrote:
>>
> [..]
>>>       type Student is limited record     -- has to be limited
> [...]
>>>       Students : array (1 .. 10) of Student;
>>
>> Doesnt this code above give warning "warning: variable "Students" is
>> read but never assigned"??
>
> Yes, because it isn't ever assigned, just declared, which means all its
> components (including the task component) exist.
>
> It *can't* be assigned, because its components are limited.
>
> So this is an over-enthusiastic warning from GNAT.

That's what 'pragma Unreferenced' is for.

-- 
-- Stephe