Re: AQ&S Guidance on pragma Elaborate_Body

[mfb@mbunix.mitre.org (Michael F Brenner)]

>>A trivial example is two packages, each of whose bodies with's the others
>>spec, which is not that uncommon.

Obviously, those are NOT elaborable by a pre-elaborate, and that is why
the more complicated elaboration pragmas exist.

> It may be true that it "is not that uncommon," but mutual dependency of
> packages indicates that you have a pair of highly cohesive abstractions,
> and they should really be combined into a single package.

It is my understanding that introduction of these highly cohesive 
structures is the only way in Ada 95 to simulate the feature that is
really needed, namely having multiple, selectable bodies for the same
generic visible part. This unfortunate situation comes about because
non-generic packages cannot be passed as generic parameters. For
example, in targetting multiple radar devices, I need to choose a 
(1) receive probabilistic pattern recognizer, (2) down converter,
(3) selection criteria enhancer, (4) display driver, (5) embodied
intelligence analysis component, (6) a boundary data structure, (7)
geometry, (8) trigonometry (spherical or flat), (9) a topological
model of the discontinuities in the antenna pattern, (10) a search
strategy, (11) a viewing surface projection transformation, (12) and
a conjugate image generator. It is easy to program this as a 
multiply cohesive hierarchical set of 12 packages each of which 
depends on the next higher level package in the partially ordered set,
forming a giant circular dependency, and substituting them by
recompiling, relinking, and re-running each time the user makes an
alternate selection. However, without the ability to pass a non-generic
package to a generic package, I do not know how to build this
system without using these <Highly Cohesive Abstractions>. A simple
cohesion metric based on variable access being more expensive at 
higher levels shows that this is, indeed, highly cohesive. In addition,
the Ada-95 requirements to explicitly give bunches of elaboration
pragmas proves beyond doubt how cohesive it is, even though Alsys
Ada has no problem figuring out the correct elaboration order. Actually,
that is not 100 percent fair, because the maintenance history of the
project indicates that some changes were made that resulted in Alsys
Ada figuring out the correct elaboration order, that is, some of 
the regression tests were removed from being executed in the 
regression test section at the bottom of some packages which were
previously executed at elaboration time.

Michael said: 
<<The goal should be that almost all of the non-thread-safe code should be
  marked ELABORATE_BODY, and almost all of the thread-safe code should be
  marked PREELABORATE or PURE.>>

Robert said: 
<I have no idea what Michael has in mind here. This has nothing at all to do
with thread safety. Elaboration and thread safety are entirely unrelated
issues. In particular, a common idiom is to complete the elaboration before
any tasks are started up.>

The link between pragma pure and thread safety is that thread safety is
a memory concern, and the concept of a pure package is to be memory-free,
and therefore as thread safe as any code can be. That is why optimizers
are permitted to optimize away multiple calls to procedures in pure
packages--they have NO memory. If they had memory, and therefore 
potential thread-unsafeness, they ARE NOT pure, and it would be fibbing
to mark them pure, and the optimized-away calls will be an undesireable
effect on the execution of the code. The purity is transitive, since
everything imported (withed) by a pure package must be pure. Therefore,
if you call, for example, some pure_io.put_line several times during
the debugging of a pure package, only the first pure_io.put_line would
actually be called!

The second, and all further calls to pure_io.put_line would generate no
code (i.e., in DEC Vaxen Ada language, would be optimized away).

By induction, all call from a pure package must be pure and therefore
memory-less, and THEREFORE thread-safe, which is strictly a memory
concern. The ONLY way something can be non-thread-safe is if two tasks
change the same memory at the same time. Admittedly, we have to include
non-purity to include memory erroneously generated by the compiler into
the code that is on the heap or on a non-threaded stack, but we can assume
that this is not an issue due to the quality of our compilers which 
correcly implement their stacks and have no cause to allocate anything
on the heap for a PURE package, since there is NO DATA to allocate.

While realtime systems normally do complete elaboration (and initialization,
self-test, regression test, and build-in-test) before any task except
the main task are started up, this has nothing to do with thread
safety. Actually most realtime systems also allocate all tasks and variables
at the beginning and avoid dynamic memory deallocations or allocations, 
but this is because of memory leakage, not thread safety.