Re: Tasks vs Task Types

Re: Tasks vs Task Types

[Norman H. Cohen]

In article <4mnra4$qc6@gde.GDEsystems.COM>, Michael Levasseur
<levass@gdesystems.com> writes: 

|> What is the difference between Tasks and Task Types?

A task is a thread of control.
  ----

Every Ada task (except the one that invokes the main subprogram) is
associated with a variable called a task object.
                                    -----------

Like every Ada object, a task object belongs to a type, called a
task type.
---------

Tasks associated with task objects of the same type have identical sets
of entries for intertask communication and execute the same task body
(each with its own copy of the variables declared inside the task body).

(The terms "task" and "task object" are often used loosely as if they
were synonymous, which can create confusion.)

The task type declaration

   task type Line_Serializer_Type is
      entry Open (File_Name: in String);
      entry Put_Line (Line: in String);
      entry Close;
   end Line_Serializer_Type;

declares a task type Line_Serializer_Type.  Given this declaration, we
can declare task objects such as the following: 

   File_1_Serializer : Line_Serializer_Type;
   File_2_Serializer : Line_Serializer_Type;

Each declaration creates a task object and a task.  Each task starts
executing the task body.  A task-type declaration must be accompanied by
a task body, such as the following: 

    task body Line_Serializer_Type is
       use Ada.Text_IO;
       File   : File_Type;
       Opened : Boolean;
    begin
       loop
          -- Task is in the "closed" state.  It can accept a call on
          --    Open, thus moving to the "opened" state, or terminate.
          --    A call on Open with a bad file name propagates an
          --    exception to the caller and leaves the task in the
          --    "closed" state.
          begin
             select
                accept Open (File_Name: in String) do
                   Create (File, Out_File, File_Name);
                   Opened := True;
                end Open;
             or
                terminate;
             end select;
          exception
             when others =>
                Opened := False;
          end;
          if Opened then
             -- Task is in the "opened" state.  It can accept a call on
             --    Close, thus moving to the "closed" state, or on
             --    Put_Line.
             loop
                select
                   accept Put_Line (Line: in String) do
                      Put_Line (File, Line);
                   end Put_Line;
                or
                   accept Close;
                   Close (File);
                   exit;
                end select;
             end loop;
          end if;
       end loop;
    end Line_Serializer_Type;

Often it is desired to create only one task belonging to a particular
task type.  In that case, there is a notational shorthand:  If you leave
the word "type" out of the declaration, it declares both an anonymous
type and a single task object belonging to that type: 

   task Line_Serializer is
      entry Open (File_Name: in String);
      entry Put_Line (Line: in String);
      entry Close;
   end Line_Serializer;

This is equivalent to having written

   task type Line_Serializer_Type is
      -- (as above)
   end Line_Serializer_Type;

   Line_Serializer: Line_Serializer_Type;

except that the declared task type doesn't really have a name.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Tasks vs Task Types

[Robert I. Eachus]

In article <4mofak$vtc@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

  > Often it is desired to create only one task belonging to a particular
  > task type.  In that case, there is a notational shorthand:  If you leave
  > the word "type" out of the declaration, it declares both an anonymous
  > type and a single task object belonging to that type...

    True but slightly misleading.  Every time the task object
declaration is elaborated, it creates a task.  All these tasks have
the same anonymous type.  In Ada 83 it was a challenge to find cases
where this mattered, ;-) In Ada 95 it is somewhat important,
especially when using some of the features of the systems programming
annex.

    But most Ada programmers never put task object declarations inside
recursively called subprograms.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Tasks vs Task Types

[Michael Levasseur]

What is the difference between Tasks and Task Types?

This relates to Pragma Priority and Size clauses.

Re: Tasks vs Task Types

[David Tannen]

In article qc6@gde.GDEsystems.COM, Michael Levasseur <levass@gdesystems.com> writes:
> What is the difference between Tasks and Task Types?

You can instantiate a generic w/ a task type but not with a task 8-).
(Think of the possibilities - link list of tasks <G>).

> 
> This relates to Pragma Priority and Size clauses.

But seriously, you have hit on the reason to do task types.  If you
need to adjust the size or priority I think the only way you can do
this is w/ a task type.  In fact, I am now in the habit of making
all my tasks task types so that I can 'fine tune' the size.


David Tannen				     (tannen@dudley.geg.mot.com)
Motorola, Scottsdale		(602) 675-1074		     m/s H1119
Member of TCCCS/Iris, TeamAda, and TeamOS/2
Christian Acronyms: B.I.B.L.E.=Basic Instructions Before Leaving Earth

Re: Tasks vs Task Types

[David Tannen]

>>>What is the difference between Tasks and Task Types?
>>
>>You can instantiate a generic w/ a task type but not with a task 8-).
>>(Think of the possibilities - link list of tasks <G>).
>>
>
>I know of code that implements a stack of tasks, where each task 
>puts ITSELF back on the stack when it is done processing.

Ted is correct, there are plenty of good reasons to use task types
and ADTs.  I have been on projects where we used a link list of
task types to control I/O between different boxes.  It worked very
well.

Sorry about being flippant.

David Tannen				     (tannen@dudley.geg.mot.com)
Motorola, Scottsdale		(602) 675-1074		     m/s H1119
Member of TCCCS/Iris, TeamAda, and TeamOS/2
Christian Acronyms: B.I.B.L.E.=Basic Instructions Before Leaving Earth