Re: Ada Tasking

Re: Ada Tasking

[W. Wesley Groleau (Wes)]

Ken Fowler of MITRE recommended:

> Real-Time Ada Design Methodologies an Their Impact on Performance, by
> Norman R. Howes.....

Ken showed me this paper when I worked with him.  I was surprised when
the paper showed the first example of the "accepted way" of accomplishing
something.  Surprised because it certainly was NOT the accepted way in
my book.  I have always been hostile to complexity that can't be PROVED
necessary to meet requirements.  Yet here was an implementation in which
half of the tasks were nothing more than buffers/FIFOs because "everybody
knows" you can't have critical tasks talking directly to each other.

(I realize that fading memory is probably distorting this a little,
but I think I'm pretty close.  Feel free to straighten me out if I'm
widely off base.)

Then Howes goes through some other options, ending with the simplest one:
NO tasks that do not represent a part of the problem on an abstract level.

I gloated a little when Howes proved that that last one was the most
efficient.  Through my career, I have CONSISTENTLY observed a high
correlation between SIMPLICITY and better computing speed.  Sinc
"everybody knows" (yeah, right) that simplicity also reduces errors,
there's no excuse for clever tricks without proof that they are needed.

--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Ada tasking

[Ted Holden]

 
 
I must have been really tired the other night to have written the little
formula for saving Ada and not mentioned tasking;  sorry.
 
From: Jeffrey M. Schweiger, Naval Postgraduate School, Monterey CA
 
>In his book, Hoare does not seem to be very upset with Ada, either, just viewing
>it as unnecessarily complicated for his purposes.  Closing out a three page
>section on Ada, he writes (page 234):
>
>"Apart from the complexities listed in the preceding paragraph, tasking in Ada
>seems to be quite well designed for implementation and use on a multiprocessor
>with shared storage."
 
>Jeff Schweiger
 
Probably the DOD got to him somehow or other;  maybe put a horses head
in bed with him like in Godfather I ...  who knows;  made him promise to
say SOMETHING nice about Ada and the statement about semetrically
parallel machines (like the Sequent) was probably all he could think of.
Ada DOES run reasonably well on the Sequent, but I should mention the
following:
 
   1.  Neither I nor any of my friends OWNS a Sequent (they cost upwards
   of $50,000 and the top-end models go for around $800,000).
 
   2.  The problems mentioned by Ms. Edwards and others concerrning
   priorities of tasks are not solved by parallelism.
 
   3.  The Sequent is a bit on the HEAVY side of it for an embedded
   system, which is the original mandate of Ada;  kind of hard to fit
   one on an F16.
 
There are numerous other reasons why the notion of Ada tasking on
multiprocessors probably won't help YOU today or tommorrow.
 
 
From: Markku Sakkinen, University of Jyvaskyla, Finland
 
>Why _should_ Hoare have mentioned a baroque language that is not
>the least bit concerned about parallelism?
 
Why should any language BE concerned with parallelism?
 
Tasking is naturally an operating system feature;  the idea of tasking
as a part of a language is one of the dumber ideas since communism.
There's no right way to do it, as a careful reading of the 750 little
"problems" should make obvious to anybody.  In all truth, I can't really
believe that any of the serious people in this group who have read
through any of that would argue this point with me.  Probably what you
want to do is to define a standard set of features to be provided by
operating systems/real-time kernals for uses which involve tasking, a
standard set of function calls, and have libraries to provide these
functions to applications which need them.
 
 
Ted Holden
HTE
 
 

Re: Ada tasking

[Vladimir G. Ivanovic]

In article <20075@grebyn.com>, ted@grebyn (Ted Holden) writes:

>Tasking is naturally an operating system feature;  the idea of tasking
>as a part of a language is one of the dumber ideas since communism.

Here are a few reasons for making tasking a language feature:

(1) The compiler can be used to check the semantics of tasking as well as its
syntax. 

(2) The same model is used by all implementations.

(3) A tasking library is limited to a procedure call interface.  One can't have
the nicely readable syntax of Ada's tasking constructs.

Cheers,

-- Vladimir
--

Vladimir G. Ivanovic			vladimir@sun.com
M/S 12-33				vladimir@prosper.ebb.eng.sun.com
Sun Microsystems, Inc.			vivanovic@sun.com

Re: Ada tasking

[Pat Rogers]

In article <20075@grebyn.com>, ted@grebyn.com (Ted Holden) writes:
> 
> From: Jeffrey M. Schweiger, Naval Postgraduate School, Monterey CA
>  
> >In his book, Hoare does not seem to be very upset with Ada, either, ...
> >   ......
>  
> Probably the DOD got to him somehow or other;  maybe put a horses head
> in bed with him like in Godfather I ...  who knows;  made him promise to
> say SOMETHING nice about Ada and the statement about semetrically
> parallel machines (like the Sequent) was probably all he could think of.
>

Well, now that Hoare has been removed from the list of supposed supporters
for this noise, with his usefulness thus lost Mr. Holden trashes his integrity.
Sheesh! 

I hope (for any of a number of reasons) that I am never considered 
a peer too. (Not likely, I know, gratefully.)

P Rogers
Software Arts and Sciences
progers@ajpo.sei.cmu.edu

Re: Ada tasking

[Charles H. Sampson]

In article <20075@grebyn.com> ted@grebyn.com (Ted Holden) writes:
 
>Tasking is naturally an operating system feature; ...

An interesting, unequivocal, statement.  No "IMHO ...", no "Many people
think ..."  A good illustration of the depth of the author's understanding
of the issues.

IMHO, many people think that the purpose of a programming language is to
express programs.  If a program is implemented using tasking, it seems
ideal to be able to express the tasking part of the program in the same
language that expresses its loops and procedure calls.  Those who de-
veloped the Ada requirements (Ironman, Steelman) had the radical idea
that it should be possible to understand a program by reading its source
code, rather than getting out the operating system services manual.

>                                                ...  Probably what you
>want to do is to define a standard set of features to be provided by
>operating systems/real-time kernals for uses which involve tasking, a
>standard set of function calls, and have libraries to provide these
>functions to applications which need them.

Maybe I missed something here, but this sounds like an argument in favor
of putting tasking into the language.  The only quibble seems to be the
syntax to be used (and presumably the semantics).  Should it be done
with constructs that look like declarations and statements, or should
it be done with "a standard set of function calls?"

None of this is intended to cover up the fact that there are problems
in this area.  I can't believe that there is anyone who believes that
Ada's tasking is just wonderful and should not be touched.  My guess is
that if anything is certain to be modified in 9X, it's tasking.  Of
course, that version 1 of Ada is imperfect is considered proof of its
worthlessness by Mr. Holden.  Does anyone remember what version 1 of
C looked like?

Charlie Sampson, CSC

Re: Ada tasking

[Richard A. O'Keefe]

In article <1921@cod.NOSC.MIL>, sampson@cod.NOSC.MIL (Charles H. Sampson) writes:
: In article <20075@grebyn.com> ted@grebyn.com (Ted Holden) writes:
: >Tasking is naturally an operating system feature; ...
: An interesting, unequivocal, statement.  No "IMHO ...", no "Many people
: think ..."

Given that Ted Holden cited Hoare, I don't think it irrelevant to remind
people who invented the CSP notation (which underlies occam, for example).
That's right.  Hoare.

The last time I heard an argument like that, it was the Algol 60
committee saying that input/output was naturally an operating system feature.
Algol 68 not only specified I/O, Algol 68 had a tasking model!

It doesn't matter whether tasking is done with special syntax or by
calling built-in procedures.  If I can use it in a portable program,
the effect of the tasking operations has to be defined _somewhere_.
The fact that fork() and signal() and semop() and the rest are library
functions in UNIX/C just means that (a) when I write a C program that
needs IPC I have to look in a language manual _and_ a library manual
and (b) my programs aren't portable.  This is a help?

The advantage of a separate tasking library is that several languages can
use the same library.  There's a lot to be said for that.  But the point
of Ada was to _reduce_ the need for using several languages.
-- 
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists.  However, no example could be found to include here."

Re: Ada tasking

[Dan Kary]

> Why should any language BE concerned with parallelism?
> Ted Holden
> HTE
 
From the first time I read the ARM I've felt that the Ada tasking
model is quite useless for solving real time problems.  However, the 
value of a programming language that is concerned with parallelism
was (and is) immediately obvious.

As computing machinery has become faster and faster, the possibilities
of what can be done with that machinery have grown.  It is becoming
increasingly obvious that physical realities (the speed of electricity,
the length of wires, etc.) will place a bound on what a single machine
may ultimately do.  An equally obvious solution to this limitation is
to use more than one machine to accomplish the desired task.

The problem with using more than one machine to accomplish a single task
is that virtually all problem solving techniques currently used involve
algorithms that presume a single thread of execution.  This is a most
unsurprising state of affairs, given that most machines and programming
languages concern themselves with a single thread of execution.

In order to make the leap to a future where multiple machines work
cooperatively to solve a single problem, the people who program those
machines will have to begin to think about parallel solutions to problems.
A language which presents a model of parallel execution that is free of
machine and operating system dependencies seems to be a useful first step.

Dan Kary

Re: Ada tasking

[Mike Harrison]

In article <20075@grebyn.com> ted@grebyn.com (Ted Holden) writes:
>
> 
> 
>I must have been really tired the other night to have written the little
>formula for saving Ada and not mentioned tasking;  sorry.
> 
>From: Jeffrey M. Schweiger, Naval Postgraduate School, Monterey CA
> ... 
> 
>Probably the DOD got to him somehow or other;  maybe put a horses head
>in bed with him like in Godfather I ...  who knows;  made him promise to
>say SOMETHING nice about Ada and the statement about semetrically
>parallel machines (like the Sequent) was probably all he could think of.
>Ada DOES run reasonably well on the Sequent, but I should mention the
>following:

I have tried quite hard recently to avoid responding directly to this 
gentleman's postings but I regret that I cannot ingore this one.

Firstly, I cannot imagine how Mr. Holden hopes to make a case against Ada by
libelling a highly respected member of the international scientific community
(particularly one who he was recently quoting in support of his tendentious
arguments).

Secondly, and on a more technical point, he writes:

>Tasking is naturally an operating system feature;  the idea of tasking
>as a part of a language is one of the dumber ideas since communism.
>There's no right way to do it, as a careful reading of the 750 little
>"problems" should make obvious to anybody.  In all truth, I can't really
>believe that any of the serious people in this group who have read
>through any of that would argue this point with me.  Probably what you
>want to do is to define a standard set of features to be provided by
>operating systems/real-time kernals for uses which involve tasking, a
>standard set of function calls, and have libraries to provide these
>functions to applications which need them.


Thus dismissing in one breath, all the work being done on parallel and
comcurrent processing. No qualification, no justification -- no sign of
understanding!

'Tasking' is merely a name for methods of expressing the notions of concurrent
or co-lateral execution. Such notions, if given a suitable medium of expression,
can be as powerful a form of abstraction for controlling the complexity of some
kinds of application as procedures and structured data types are for others.

The ability to choose an appropriate level of granularity for such co-lateral
threads of computation is just as important as the ability to use procedures
and functions whose bodies may be quite trivial, but which improve the clarity
of expression. (Perhaps Mr. Holden never uses macros in any of his C programs).

'Fine grain' parallelism clearly cannot be achieved by relying on the services
offered by operating systems or 'run-time kernels', (at least for the general
run of machines to which Mr. Holden would have us restrict ourselves). [ the
Sequent is too expensive, etc.].

It follows that to the full range of expression which programmers and engineers
now require can only be met by integrating the mechanisms of parallelism into
the language.
This Ada has done.

I am puzzled by Mr. Holden's motives in continuing to post his poisonous libels
in this group. I am sure that no-one objects to intelligent criticism of Ada,
even if it is primarily destructive in nature, so long as it is expressed in a
civil manner, but Mr. Holden acts in a way more befitting a fractious 4 year
old child.

More in sorrow than in anger,

Mike,



Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;

Ada tasking

[John R. Mudd]

I am looking for information concerning Ada tasking and how it may not 
be the best way to express concurrency.  I would like to see papers 
dedicated to the topic from proceedings or tech reports, not simply sections 
from papers on concurrency, unless the paper has a good discussion of the 
Ada tasking model and its drawbacks.

Unfortunately, there's an extra twist.  Ohio State doesn't have proceedings
from *any* Ada conference--it does get SIGada--so if you suggest a paper
and your description matches what I'm looking for, I may have to ask you
to send me a copy.  I'm sorry about that, but this library is in a pretty
sad shape.

I also be interested in talking to people who have interfaced C routines
into their Ada programs.  

    John

-------------------------------------------------------------------------------
  John R. Mudd                                     mudd-j@cis.ohio-state.edu
  Department of Computer and Information Science,  The Ohio State University
  2036 Neil Avenue, Columbus, Ohio, USA   43210-1277