ADA Tasks

ADA Tasks

[Khuram Imtiaz]

Is it possible to have tasks which contain both (entries/accepts and
calls).Could this be a bad idea? If so, why? can someone explain it
with a pseudo code. I would appreciate your help in this regard.

Re: ADA Tasks

[James S. Rogers]

"Khuram Imtiaz" <khurmie@hotmail.com> wrote in message
news:a5a588a6.0212011837.5e378fd6@posting.google.com...
> Is it possible to have tasks which contain both (entries/accepts and
> calls).Could this be a bad idea? If so, why? can someone explain it
> with a pseudo code. I would appreciate your help in this regard.

There are two fundamental ways for tasks to communicate with
each other. The oldest is the Rendezvous. The newest is
protected objects.

The Rendezvous provides direct, synchronous communication
between tasks. Protected objects allow indirect, asynchronous
communication through shared data.

There is no way to define a "call" other than an Entry or a
protected operation between tasks.

Jim Rogers

Re: ADA Tasks

[Richard Riehle]

Khuram Imtiaz wrote:

> Is it possible to have tasks which contain both (entries/accepts and
> calls).Could this be a bad idea? If so, why? can someone explain it
> with a pseudo code. I would appreciate your help in this regard.

An important point to remember about an entry is that it has a queue.
A subprogram does not have a queue.   In concurrency this is important
because an entry call is not a call for immediate action.   Rather, an
entry call simply places an entry ( a request for action) in the queue.

Almost every other mechanism in tasking relies on this simple idea.
For example, timed entry calls, conditional entry calls, asynchronous
transfer of control, etc. all depend on the notion of an entry queue.

If a task had a subprogram, we would expect an immediate response
upon calling it.   At the very least, we would expect the call to
be re-entrant.  That would have some strange implications for any
active object (task).

On the other hand, a passive object (protected object) can accomodate
the mixture of entries and subprograms quite easily.

Hope this is helpful.

Richard Riehle

Re: ADA Tasks

[Robert A Duff]

khurmie@hotmail.com (Khuram Imtiaz) writes:

> Is it possible to have tasks which contain both (entries/accepts and
> calls).Could this be a bad idea? If so, why? can someone explain it
> with a pseudo code. I would appreciate your help in this regard.

Yes, a task is allowed to contain both entries/accepts and entry calls.
There is nothing particularly "bad" about it, if it meets your needs.
For example, task A might call task B's entry, and as part of the work
in (or after) the accept statement in B, B might call an entry of task
C.

However, protected objects are often a better way to communicate than
rendezvous, because they decouple the communicating tasks.  They are
also more efficient on many implementations.

- Bob

Re: ADA Tasks

[Jean-Pierre Rosen]

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


"Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message news:
wccbs44qwoz.fsf@shell01.TheWorld.com...
> khurmie@hotmail.com (Khuram Imtiaz) writes:
>
> However, protected objects are often a better way to communicate than
> rendezvous, because they decouple the communicating tasks.  They are
> also more efficient on many implementations.
>
However, they make proper termination more difficult, and are (IMHO) of
lower level than rendezvous.
As usual, having a choice means that you have to make a choice...

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: ADA Tasks

[Dmitry A. Kazakov]

On Mon, 2 Dec 2002 16:46:45 +0100, "Jean-Pierre Rosen"
<rosen@adalog.fr> wrote:

>"Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message news:
>wccbs44qwoz.fsf@shell01.TheWorld.com...
>> khurmie@hotmail.com (Khuram Imtiaz) writes:
>>
>> However, protected objects are often a better way to communicate than
>> rendezvous, because they decouple the communicating tasks.  They are
>> also more efficient on many implementations.
>>
>However, they make proper termination more difficult,

... and they are unable to exchange data. Technically it is possible
using Requeue, but it is so painful and error prone that one should
better use rendezvous [for that].

>and are (IMHO) of lower level than rendezvous.

A level measured in what? (:-)) They are really difficult to compare.
But both have the same problem, they do not very support refactoring.
Neigther protected object nor task can be extended or split, leaving
the interface intact.

>As usual, having a choice means that you have to make a choice...

!

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ADA Tasks

[Simon Wright]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

{re: tasks vs protected objects

> But both have the same problem, they do not very support
> refactoring.  Neigther protected object nor task can be extended or
> split, leaving the interface intact.

Do you have something in mind that allows refactoring _and_
concurrency?

Re: ADA Tasks

[Dmitry A. Kazakov]

On 03 Dec 2002 22:06:44 +0000, Simon Wright <simon@pushface.org>
wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>{re: tasks vs protected objects
>
>> But both have the same problem, they do not very support
>> refactoring.  Neigther protected object nor task can be extended or
>> split, leaving the interface intact.
>
>Do you have something in mind that allows refactoring _and_
>concurrency?

No. Ada is the single language which seriously tries to express
concurrency. Others are more or less just toys. So there is nothing to
compare with.

If you ask whether it is possible to do it, then I believe it should
be possible, but a long way to go.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de