From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!necntc!linus!alliant!werme From: werme@alliant.Alliant.COM (Ric Werme) Newsgroups: comp.lang.ada Subject: Re: Legal and Ethical Questions Message-ID: <799@alliant.Alliant.COM> Date: Thu, 29-Oct-87 01:49:26 EST Article-I.D.: alliant.799 Posted: Thu Oct 29 01:49:26 1987 Date-Received: Wed, 4-Nov-87 06:51:25 EST References: <8710201049.AA16580@ajpo.sei.cmu.edu> Reply-To: werme@alliant.UUCP (Ric Werme) Organization: Alliant Computer Systems, Littleton, MA List-Id: In article <8710201049.AA16580@ajpo.sei.cmu.edu> eberard@AJPO.SEI.CMU.EDU writes on handling concurrency and determinism and asks the following questions. As an old time OS and realtime programmer (someone at CMU may still remember!) I'll toss my two bits in. For the purpose of this discussion, I'll concentrate on a system that is a realtime control system, i.e. an Ada program controlling an electro-mechanical system (be it rocket, power plant, dot-matrix printer, whatever). > 1. If an Ada software engineer just happens to know what the > underlying scheduling algorithm is, should he or she design their > Ada software in a manner which takes direct advantage of this > knowledge? In general any engineer should design for maximum portability and maintainability - unless the situation presents a strong reason otherwise. Taking advantage of local scheduling algorithms is not real portable.... On the other hand, knowing things like the time slice size is useful for, uh, well, it must be useful for something. I've never needed it. I have used the clock interrupt rate in a number of systems, that might apply here. > 2. Should an Ada software developer require that an Ada development > system vendor supply the scheduling algorithm for tasking, with > the intention of using this knowledge in the design and > implementation of the Ada software? Absolutely, if it's absolutely necessary. On a dot matrix printer I worked on I had to feed a FIFO every 500 usec. If I wanted to implement it in Ada (on a Z8??) I would ask about task response times before asking about anything else about the compiler. On the other hand, If I were writing a simulation of something, timing would be essentially no issue at all. > 3. How much "tailoring" of an Ada development is to be allowed? > Specifically, at what point (or points) do we cross the line > between issues which are truly outside of Ada, and issues which > are best left to "language lawyers"? ;l In some systems, much of the scheduling will be outside of Ada's domain. Alliant's Ada V1.1 is a good example. Our runtime has it's own task scheduler that schedules tasks on various processors. The tailoring within the Ada domain is the number of processors to use. For each processor we spawn a Unix process and the runtime runs tasks on any available process. Processors include IPs (slow I/O processors based on 68020's) and CEs (Fast computational processors designed for number crunching). We also allow tasks to run on the complex, a group of CEs running "concurrently". In our sense, concurrent means several CPUs running a single program in parallel. While the LRM makes it hard for Ada to do the vector/concurrent math the complex is for, we let Ada code call Fortran code to do fast matrix operations. On top of this Ada tailoring, we have hooks into Unix that adjusts the number of CEs devoted to the complex and the amount of time they run as the complex. All this makes it awfully hard to publish a description of how our tasks are scheduled, and even harder to take advantage of the scheduler. And of course, since the system is timeshared with other users, there's no way you'll get anything deterministic. > 4. If certain types of tailoring or knowledge of the underlying > implementation are to be discouraged, what alternatives are > available to the Ada software developers? I'm only working on Ada temporarily, so I'm not sure what you need. In general, the realtime, multitasking software I've worked on needs: 1) High priority tasks - things that get cycles as soon as possible when it needs them. 2) Access to interrupt service routines. These run essentially outside of tasks, and I don't think are covered by the LRM. 3) Interprocess communication (which can become interesting when a high priority task fills the buffers going to a low priority task). 4) Multiple priority levels - often useful in fixing problems due to 3). 5) Guaranteed access - tasks sometime need say, a second of cpu time every ten seconds. For example, a task that positions the control rods in a fission reactor isn't high priority, and doesn't have to be done on a regular basis, but it does need to be done. (Incidentally, process control systems have been all but ignored by computer science, although many of its discoveries are applicable. Scheduler research is good example - everything I've read has been on getting things done as efficiently as possible. My father designed a process control computer that had a hardware scheduler that switched register sets (including the PC) each clock tick. Sort of the ultimate round robin scheduler.) I fondly remember a couple of graphics hacks I wrote using a PDP-11 P&V kernel a friend wrote at Harvard. It didn't do much about interprocess communication or guaranteed access, but it handled the rest very nicely. > 5. Are there published lists of questionable practices relating to > the above? Are there any published policies? I can't help on this, except to suggest listening to what OS people have to say. The race conditions we have to deal with in OS's can be awfully painful to track down (they're even worse in networking - just ask them!) I suspect that many Ada programmers will be surprised and ill prepared to deal with such things. 6. Can determinism be achieved? [My question] No. At least, not in many systems that deal with the real world. Consider the carriage of a dot matrix printer. The carriage motor drives the head back and forth. With a stepping motor things may be deterministic, with a DC motor they can't be. Different motors have different torques, the bearings have different frictions, and everything changes with age. Each pass of the printhead will be as different as snowflakes. I don't worry about about determinism in software - I haven't seen much of it in my 19 years with computers. The biggest challenge in my mind is writing debuggers that can handle a multi-tasking environment and can simulate the various timing problems that will occur. It may be that Ada, with all its handholding and insistance on programming structure, may become best known for the new minefield it's springing on the unwary. -- | The Art of Programming | Eric J Werme | | needs to be tempered with | uucp: decvax!linus!alliant | | the Structure of Engineering | Phone: 603-673-3993 |