Legal and Ethical Questions

[eberard@AJPO.SEI.CMU.EDU]

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