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.8 required=5.0 tests=BAYES_00,INVALID_DATE 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!husc6!rutgers!sri-spam!ames!sdcsvax!ucbvax!AJPO.SEI.CMU.EDU!eberard From: eberard@AJPO.SEI.CMU.EDU Newsgroups: comp.lang.ada Subject: Legal and Ethical Questions Message-ID: <8710201049.AA16580@ajpo.sei.cmu.edu> Date: Tue, 20-Oct-87 06:49:55 EDT Article-I.D.: ajpo.8710201049.AA16580 Posted: Tue Oct 20 06:49:55 1987 Date-Received: Wed, 21-Oct-87 20:45:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: Concurrency is a concept that seems simpler than it really is. Most people can easily envision two or more "processes" executing simultaneously. However, concepts such as how concurrency behaves on a single processor system as opposed to a multiple processor system, deadlock, starvation, race condition, and inter-process communication are not easily understood. One of the fundamental characteristics of concurrency that is difficult for most people to understand is the concept of indeterminacy. Sequential software is deterministic i.e., one can predict precisely how the software will behave (even at a microscopic level of detail) for a given set of conditions. Concurrent software, on the other hand, is nondeterministic. Specifically, while the macroscopic behavior of the software may be reasonably predictable, the microscopic behavior of the software cannot be predicted with a high degree of precision. Few programmers have an in-depth understanding of concurrency issues. For example, there have been any number of complaints that "Ada does not allow the programmer easy access to the underlying scheduling algorithm," or that "Ada does not have a specific (published) scheduling algorithm." Complaints such as these indicate little knowledge of concurrency in software. It is important for Ada software engineers to realize that if they wish their concurrent software to behave in the same general manner with any given Ada system, it is possible to implement their source code in such a manner so that this can be accomplished, regardless of such things as the underlying implementation of the scheduling algorithm. Recently, I have become aware of some attempts to get around the "problem" of nondeterminism in concurrent Ada software. The code word here is "tailoring." For example, some Department of Defense (DoD) contractors have required that Ada development system vendors allow their customers to supply their own scheduling algorithms for tasking. (Note: All requests for tailoring are not attempts to circumvent good software engineering. It is entirely reasonable for software engineers to request some degree of tailoring. Further, there is a certain degree of flexibility allowed by the standard. Finally, there are issues which are truly "outside of Ada," and are properly addressed by tailoring.) "So what is the big deal," you ask, "if some DoD contractor requires that the scheduling algorithm for tasking be supplied by the Ada development system vendor, or that the vendor allow the contractor to 'tailor' the scheduling algorithm?" Suppose that the Ada software is sold to the government and that it is recompiled in part, or in whole, using a different Ada compiler. The software may not only behave in an erroneous manner, but the cause of the erroneous behavior will not be easily determined from a knowledge of the source code alone. Further, suppose that all members of the development team are not informed about the (now deterministic) task scheduling algorithm, or that maintenance personnel are equally uninformed. Developing, testing, debugging, and maintaining concurrent software is difficult enough without attempting a partial removal of indeterminacy. So we have a number of technical, legal, and ethical questions: 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? 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? 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"? 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? 5. Are there published lists of questionable practices relating to the above? Are there any published policies? On one hand, I am aware that some of the issues I have raised can be resolved by "language lawyers." On the other hand, some of these questions (and others) are clearly outside of domain of the Ada language definition. -- Ed Berard (301) 695-6960 eberard@ajpo.sei.cmu.edu