mudd-j@bear.cis.ohio-state.edu (John R. Mudd) (12/02/88)
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
ted@grebyn.com (Ted Holden) (05/25/90)
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
vladimir@prosper (Vladimir G. Ivanovic) (05/25/90)
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
progers@ajpo.sei.cmu.edu (Pat Rogers) (05/26/90)
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
sampson@cod.NOSC.MIL (Charles H. Sampson) (05/26/90)
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
kary@hp-lsd.COS.HP.COM (Dan Kary) (05/26/90)
> 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
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/26/90)
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."
mph@lion.inmos.co.uk (Mike Harrison) (05/29/90)
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;