Re: Task Problem

Re: Task Problem

[Matthew Heaney]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> -----Original Message-----
> From: Sean Hill <shill@arlut.utexas.edu>
> To: chat@gnat.com <chat@gnat.com>
> Date: Thursday, April 08, 1999 4:03 PM
> Subject: Task Problem
>
> >Any thoughts out there?
> >
> I know this is not a first step when porting from Ada83 to Ada95, but
> I have found no need for the rendezvous mechanism in any of my new
> designs, and have changed many rendezvous designs to use protected
> queues.

I'll ditto that.  It's possible to write Ada tasks as pure active
threads, with no entries.  When you need to call a task, you call a
protected object instead that acts as an intermediary.

I'm no expert in these matters, but I suspect that this would allow very
efficient run-times to be built.  You could have light-weight tasks that
don't have accept statements or terminate alternatives.

One of the things I'd like to do is build a run-time like that for GNAT
(or for any Ada compiler), along the lines of a Ravenscar profile.

For example, the Implementation Advice section of the GNAT reference
manual reads:

(start of quote)
*D.7(21): Tasking Restrictions*
     When feasible, the implementation should take advantage of the
     specified restrictions to produce a more efficient
     implementation.

     Not followed. GNAT does not currently take advantage of any
     specified restrictions.
(end of quote)

It would be cool to build different run-times tailored to specific sets
of restrictions, to get maximum efficiency.

Anybody know how to do this?

Re: Task Problem

[Robert Dewar]

In article <m3emltz10g.fsf@mheaney.ni.net>,
 "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

 > -----Original Message-----
 > From: Sean Hill <shill@arlut.utexas.edu>
 > To: chat@gnat.com <chat@gnat.com>
 > Date: Thursday, April 08, 1999 4:03 PM
 > Subject: Task Problem
 >
 > >Any thoughts out there?
 > >
 > I know this is not a first step when porting from
 > Ada83 to Ada95, but I have found no need for the
 > rendezvous mechanism in any of my new
 > designs, and have changed many rendezvous designs
 > to use protected queues.

Certainly this is possible, but it inevitably ends up
with a lower level design. This is because protected
objects are extremely restrictive in what they can do,
they are not a general Ada building block. In any
protected object, you have to know whether any procedure
you might call is potentially blocking, something you
don't know from the spec.

We find people writing a LOT of invalid code in which
protected objects do in fact make blocking calls, and
we know at least one user who absolutely depends on this
behavior.

That's a bit worrisome.

Obviously a rendezvous can be implemented as efficiently
as a protected object interaction in a similarly
restricted case (that is what passive tasks were all
about in some Ada 83 implementations), so efficiency
is not really the issue here (from a language point
of view).

From my point of view, some problems are more naturally
solved with the RV, some with PT. The Burns and Welling
Realtime book is a very nice source of considerations of
various ways of using both constructions to solve
typical RT problems.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Task Problem

[charlet]

> One of the things I'd like to do is build a run-time like that for GNAT
> (or for any Ada compiler), along the lines of a Ravenscar profile.

Note that the development version of GNAT has now such optimized run time
based on the Ravenscar profile, so the quote of the GNAT RM you showed is
(fortunately) obsolete ;-)

Arno

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Task Problem

[Jean-Pierre Rosen]

Matthew Heaney a �crit dans le message ...
>"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
>
>> -----Original Message-----
>> From: Sean Hill <shill@arlut.utexas.edu>
>> To: chat@gnat.com <chat@gnat.com>
>> Date: Thursday, April 08, 1999 4:03 PM
>> Subject: Task Problem
>>
>> >Any thoughts out there?
>> >
>> I know this is not a first step when porting from Ada83 to Ada95,
but
>> I have found no need for the rendezvous mechanism in any of my new
>> designs, and have changed many rendezvous designs to use protected
>> queues.
>
>I'll ditto that.  It's possible to write Ada tasks as pure active
>threads, with no entries.  When you need to call a task, you call a
>protected object instead that acts as an intermediary.
>
One big (huge in some cases) drawback of this approach is that you
have no way to ensure automatic termination of servers.
With this paradigm, every task is in the position of a client, and the
PO work as the servers. You must send some kind of message to tell the
tasks to terminate, but it is difficult to ensure that every task will
terminate properly in every case of exception.

Of course, this does not apply if all tasks are intended to be
permanent (which often happens in real-time systems).
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog