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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,baa6871d466e5af9 X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/25 Message-ID: <5jq9uc$kuf@top.mitre.org> X-Deja-AN: 237295307 References: <528878564wnr@diphi.demon.co.uk> <5jfukp$lda@top.mitre.org> Organization: The MITRE Corporation, Bedford Mass. Newsgroups: comp.lang.ada Date: 1997-04-25T00:00:00+00:00 List-Id: >>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 . 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: <> Robert said: 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.