Ada Protected Object Turorial #2: Overview of Tasks

Ada Protected Object Turorial #2: Overview of Tasks

[James S. Rogers]

Overview of Ada Tasks.

Tasks are entities whose execution may proceed in parallel.

A task is an object of a task type. As with other types in Ada,
the task type may be explicitly named by the programmer, or
it may be an anonymous type.

Task objects are created in the same ways as other objects:
they may be declared by an object declaration, or created
dynamically using an allocator. Tasks may be nested within
other program units, in the same manner as subprograms
 (procedures and functions) and packages.

Common task activities:

Task Creation:

A task is created when it is declared or dynamically allocated.
The creator can communicate with the task during creation by
 initializing discriminants to the task.

Task Activation:

After creation the creator waits for the task to activate.
No explicit action is required by the creator. The task will
automatically activate as a result of its creation.

Task Termination:

Every task has a master. The master cannot terminate until
all the tasks it created terminates. The created tasks are called
children of the master. A task will terminate when it completes
all its activities. It can also be terminated by the master through
an abort command.

Rendezvous:

A rendezvous is a method for tasks to communicate directly
with one another. The rendezvous synchronizes tasks at the
point of communication. A calling task calls an entry in another
 task. The called task accepts the entry call. If the calling task
 calls the entry before the called task is ready to accept it, the
calling task will wait for the called task. If the called task reaches
 the accept point before the calling task calls the entry, the
called task will wait for a calling task.  Entry parameters allow
data to be passed between tasks during a rendezvous.

Protected Objects:

Protected objects provide mutual exclusion for data in shared
memory between tasks. They allow tasks to communicate
either synchronously or asynchronously. Tasks communicate
indirectly by reading and writing components of the protected
objects.

Unprotected Shared Variables:

Ada does allow you to use unprotected shared variables so
that you can implement user-defined low level synchronization
between tasks. It is the responsibility of the developer to
ensure the integrity of the data.

In addition to the basic tools described above, Ada provides
finer control of the interactions between tasks through the many
uses of the select clause.

The select clause can be used to allow a task to accept several
different entry calls each time through a loop, much like
processing a case statement.

The select clause can have a delay alternative, allowing a calling
task to limit the amount of time it waits for the called task to
accept the entry, or for a protected object to open the block on an entry.

The select clause can have an abort option, allowing two activities
to proceed simultaneously. When one of the options finishes the
other option is automatically aborted. This is called Asynchronous
Transfer of Control. One of the options must be an entry call or a delay.
The other option is defined as the abortable part of the statement.
An example lifted from the Ada 95 Rationale concerns having a
database operation cancelled by typing a special key on the input device.

declare
   Database_Txn : Transaction;
   -- declare a transaction, commit or abort during finalization
begin
   select
      -- wait for a cancel key from the input device
      Input_Device.Wait_For_Cancel;
      -- the Satus remains Incomplets, so that the transaction will not
commit
   then abort
      -- do the transaction
      Read(Database_Txn, ...);
      Write(Database_Txn, ...);
       ...
       Set_Status(Database_Txn, Succeeded);
       -- set status to ensure the transaction is committed
   end select;
   -- Finialize of Database_Txn will be called here and,
   -- based on the recorded status, will either commit or
   -- abort the transaction.
end;


I have left out the details of how the transaction type is defined so
that Finalization handles the roll-back or commit of the database.
In C++ terms, this would be handled by the destructor for Database_Txn.

Ada clearly has more to offer concurrent programming than the
ability to create threads and create mutexes. Most of your
concurrent programming needs can be handled by the tools
Ada provides, without forcing the programmer into more risky
low level programming. At the same time, Ada allows the
programmer to perform all the risky low level programming
required to do the job.

Jim Rogers
Colorado Springs, Colorado

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert Dewar]

In article <83hu2h$bba$1@bgtnsc01.worldnet.att.net>,
  "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote:

> declare
>    Database_Txn : Transaction;
>    -- declare a transaction, commit or abort during
>    -- finalization
> begin
>    select
>       -- wait for a cancel key from the input device
>       Input_Device.Wait_For_Cancel;
>       -- the Satus remains Incomplets, so that the transaction
>       -- will not commit
>    then abort
>       -- do the transaction
>       Read(Database_Txn, ...);
>       Write(Database_Txn, ...);
>        ...
>        Set_Status(Database_Txn, Succeeded);
>        -- set status to ensure the transaction is committed
>    end select;
>    -- Finialize of Database_Txn will be called here and,
>    -- based on the recorded status, will either commit or
>    -- abort the transaction.
> end;


The above is in fact a good example of how dangerous ATC can
be. In order to program in this manner, the entire database
update operation must be made abort safe. This is really tricky
to do, especially in the light of allowed 11.6 optimizations.
In practice it will be necessary to defer aborts at critical
points, but the language only offers kludgy ways to do this in
a general manner:

  a) use a protected type, but then you have to worry about not
     doing potentially blocking operations.

  b) introduce arbitrary finalization handlers and do things as
     bogus finalization steps.

In GNAT, you can use pragma Abort_Defer, which is far cleaner
but implementation dependent. We introduced this pragma because
it really seems that without it you can't use AST reasonably
at all, and there are other situations where deferring abort
is preferable. In general it is far easier to defer an abort
than take it and then desparately try to undo the ill effects
in a finalization handler, not knowing exactly what has and
has not actually been done at the point of the abort. Yes of
course you can fragment the operation into steps with a
finalization handler for each step, but even this is tricky,
especially since it requires a kludge to get a simple
finalization handler for a block of code (have to declare a
bogus controlled object)

All in all, a good rule in Ada 95 is not to use ATC. I know
that I generally say that any rule saying "don't use feature
X" is a mistake since the feature would not be in the language
unless it had been carefully thought out and understood to
be useful. However, in my opinion [not new, I strongly opposed
adding this feature] ATC is NOT a desirable feature in Ada :-)

I just trimmed this to CLA, since it is rather too Ada specific
for comp.threads.

Robert Dewar


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

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Tucker Taft]

Robert Dewar wrote:
> ...
> All in all, a good rule in Ada 95 is not to use ATC. 

My view is that ATC is dangerous, but important in some
situations where polling is impractical.  It is somewhat safer 
than setjmp/siglongjmp, which is a standard, and relatively 
frequently (mis?)used, feature of ANSI C and POSIX.

Note that most "production quality" database systems operate
under the presumption that the power cord can be unplugged
at any moment.  Abort is somewhat less catastrophic than that...

> ...
> 
> I just trimmed this to CLA, since it is rather too Ada specific
> for comp.threads.

And politically incorrect ;-)
> 
> Robert Dewar

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert Dewar]

In article <385E9343.1D23B0C5@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Note that most "production quality" database systems operate
> under the presumption that the power cord can be unplugged
> at any moment.  Abort is somewhat less catastrophic than
> that...

Or they run on machines with multiple power cords and multiple
disks, where no one can unplug anything successfully :-)

Clearly if you have a full commit rollback system, then you
can indeed rollback on an abort, but still I find the legitimate
uses of ATC very few. Almost always it is better to have a high
priority task preempt to perform the time critical stuff, and
then cleanly abort the lower priority stuff by polling.


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

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert I. Eachus]

Robert Dewar wrote:

> All in all, a good rule in Ada 95 is not to use ATC. I know
> that I generally say that any rule saying "don't use feature
> X" is a mistake since the feature would not be in the language
> unless it had been carefully thought out and understood to
> be useful. However, in my opinion [not new, I strongly opposed
> adding this feature] ATC is NOT a desirable feature in Ada :-)

   ATC is IMHO only useful in one very specific situation, but in that
case it is critical.  If you are building a fault tolerant system, you
need to be able to recover from the failure of some other component of
the system.  An example important to Ada's original intended use is in
round-robin schedulers for real-time systems.  In Ada 83 it is possible,
but very kludgy, to write a real-time cyclic executive.  But worse, if
the executive has to abort a task that  is overruning its time slot, it
must use an unlimited abort, which can cause nasal demons and other
effects unacceptable in safety-critical systems.  With ATC, it is
possible to migrate the time budget downward into the application, and
any operation that may exceed its budget can be wrapped in an ATC which
carefully limits the possible chaos.  In general, the abortable region
will be written as a procedure that cannot or will not access global
data.  After an ATC, the values of the out or in out parameters to the
call can and must be ignored.  Consider a radar system where there is an
algorithm whose execution time depends on the received data.  With ATC,
it is possible to discard data from one pulse and go on to the next. 
(This is necessary because the "bad guys" out there may be using all
sorts of electronic countermeasures and jamming.  If you can just
determine the jammed azimuth, it is possible to use triangulation to
find the source...

-- 

                                        Robert I. Eachus

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

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert A Duff]

Robert Dewar <dewar@gnat.com> writes:

> All in all, a good rule in Ada 95 is not to use ATC.

Do you feel the same way about abort statements?

To me, abort statements and ATC seem equally error prone.
I wouldn't go so far as to outlaw either one, but it seems to me that if
you want to outlaw ATC, you should also want to outlaw abort
statements.

>... I know
> that I generally say that any rule saying "don't use feature
> X" is a mistake since the feature would not be in the language
> unless it had been carefully thought out and understood to
> be useful.

I don't really agree with that -- it implies that the language designer
was a god.  This issue is a good example -- you have every right to
express the opinion "don't use ATC", so long as you realize that you are
really saying that the language designers made a mistake in putting the
feature in in the first place.

I don't happen to agree with that, because polling seems too painful in
some cases.

>... However, in my opinion [not new, I strongly opposed
> adding this feature] ATC is NOT a desirable feature in Ada :-)

Yes, I remember.  ;-)

I also remember that many of the anti-ATC reviewers also outlawed abort
statements -- but I don't remember your opinion on that point.

- Bob

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert A Duff]

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

> It would be like saying that since exceptions are a form of
> non-local gotos, that it makes sense to allow general non-local
> gotos :-)

Interesting.  You're obviously implying that the above argument is
patently absurd, but I'm not so sure it is!  ;-)

I used to use non-local gotos in Pascal once in a while, and I didn't
find them so horrible.  At least with a goto, you know where you're
going to.  Exceptions are less readable, in the sense that you might be
jumping to who-knows-where.  (Of course that's the whole *point* of
exceptions -- to separate the detection of an exceptional situation from
the determination of what to do about it.)

Of course non-local gotos in Ada would make no sense: I can't imagine
what it would mean to goto from a procedure into a different task, and
Ada doesn't provide any way to tell (at compile time) what tasks are
running what procedures.

- Bob

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert Dewar]

In article <wccpuvxadvz.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > It would be like saying that since exceptions are a form of
> > non-local gotos, that it makes sense to allow general
non-local
> > gotos :-)
>
> Interesting.  You're obviously implying that the above
> argument is patently absurd, but I'm not so sure it is!  ;-)

OK, you are not sure that non-local gotos in Ada are nonsense.



> Of course non-local gotos in Ada would make no sense:

Hmm! and now you agree they are nonsense

So I am a bit confused :-)


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

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert Dewar]

In article <wcc7li7uhii.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Robert Dewar <dewar@gnat.com> writes:
>
> > All in all, a good rule in Ada 95 is not to use ATC.
>
> Do you feel the same way about abort statements?
>
> To me, abort statements and ATC seem equally error prone.
> I wouldn't go so far as to outlaw either one, but it seems to
me that if
> you want to outlaw ATC, you should also want to outlaw abort
> statements.


Nope! I don't consider them the same. Abort is only to be used
in extreme or error conditions, the trouble with ATC is that
it invites the abort paradigm to be used as a general purpose
control structure. I know that the above supposed equivalence
was used to argue for the inclusion of ATC, but I regard it as
a bogus argument!

It would be like saying that since exceptions are a form of
non-local gotos, that it makes sense to allow general non-local
gotos :-)


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

Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert A Duff]

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

> OK, you are not sure that non-local gotos in Ada are nonsense.
> 
> > Of course non-local gotos in Ada would make no sense:
> 
> Hmm! and now you agree they are nonsense
> 
> So I am a bit confused :-)

;-)

I'm saying that non-local gotos are not such a horrible idea in the
abstract.  I also say that you couldn't add them to Ada without major
surgery.  But since we're talking about language design, we don't have
to imagine very specifically sticking to Ada's rules.  The reason
non-local gotos wouldn't work in Ada is accidental, not fundamental.

In other words, I believe I could design an Ada-like language that
allowed non-local gotos.  And the non-local gotos would not be
particularly more dangerous than exceptions.

- Bob