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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fc232b1f37897ed0 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: D.10 Date: 1999/04/13 Message-ID: #1/1 X-Deja-AN: 465918512 Sender: bobduff@world.std.com (Robert A Duff) References: <7evc8l$pde$1@nnrp1.dejanews.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-04-13T00:00:00+00:00 List-Id: Robert Dewar writes: > My advice is to stay completely away from this feature > in the language. It is gratutious nonsense if you ask > me. It consists of one particular, not very well thought > out second level primitive. > > Much better to define your own. That kind of statement would have more credibility if you gave some reasons. ;-) My experience is just the opposite: Averstar's Ada run-time system is fundamentally based on suspension objects as the main means of suspending tasks. We can't "define our own" in terms of protected objects, because we're *implementing* protected objects. Suspension objects are a lower-level primitive. I find suspension objects to be quite a clean feature to use; race conditions are more easily eliminated than with (for example) a Suspend_Self/Resume_Other pair of operations. I know of one customer that uses suspension objects, for example, to communicate between interrupt handlers and tasks in a way that is more efficient than protected objects. The key to the efficiency is that there can never be more than one task waiting. I don't think it's feasible to make the compiler automatically optimize a normal protected object in a similar way, because how is it supposed to know about this special (rather global) property. (Well, I suppose you could have a pragma.) > Possibly your implementation might do something specially > efficient with this package, it might also do something > specially efficient with simple cases of protected records. I don't see how a compiler can be expected to figure out that only one task will ever suspend on a given protected entry. The programmer has to tell the compiler. Using suspension objects does that. I can imagine other mechanisms for telling the compiler, but I can't imagine a totally automatic optimization along these lines. > Certainly GNAT just translates this into the corresponding > protected type in a naive way, and we have never seen a > program that used it except an ACVC test or two :-) Perhaps GNAT isn't used so much in the same sort of real-time embedded systems where this kind of efficiency issue is so important, and perhaps that's why your customers don't use it. Or perhaps they don't use it because you haven't implemented it efficiently -- the language design can make optimizations feasible, but it can't force implementers to do them. If we're talking about implementing Ada on top of a typical operating-system threads implementation, then efficiency is hopeless anyway, so of course folks aren't going to be worrying about suspension objects. - Bob P.S. The following section, D.11, Asynchronous Task Control -- now *that's* gratuitous nonsense. ;-) -- Change robert to bob to get my real email address. Sorry.