brendan@batserver.cs.uq.oz.au (Brendan Mahony) (09/26/90)
I am a little confused about the exect meaning of unboundedness in the discussion of recursion. Do you mean absolute bounds are required rather than function bounds? Non-determinism was mentioned, so you might be complaining about truly unbounded execution times. In any case how can a compiler be expected to distinguish the bounded loop from the unbounded? Do you wish to remove loops entirely? I'd say many real-time (embedded) systems have a fervent hope that they will not terminate until the holocaust of the FINAL POWER DOWN. So logically-infinite loops are needed. You know things of the sort while true do keep that reactor running I don't really see why loops are any more dangerous in RT. You need to do more thorough analysis of their behaviour, but that is true for all RT programming. Non-terminating calculations are not appreciated in any program. -- Brendan Mahony | brendan@batserver.cs.uq.oz Department of Computer Science | heretic: someone who disgrees with you University of Queensland | about something neither of you knows Australia | anything about.
mcmahan@netcom.UUCP (Dave Mc Mahan) (10/01/90)
In a previous article, brendan@batserver.cs.uq.oz.au writes: >I am a little confused about the exect meaning of unboundedness in the >discussion of recursion. Do you mean absolute bounds are required rather >than function bounds? Non-determinism was mentioned, so you might be >complaining about truly unbounded execution times. It is my understanding that an unbounded loop has the possibility of hanging for ever while waiting for a stop condition that might not occur. Such an event might look something like: while (waiting_for_data_arrival) { Do_nothing_but_wait(); } Instead, it would be better to write such a thing as: while (waiting_for_data_arrival && !timeout_while_waiting) { Do_nothing_but_wait(); } if (timeout_while_waiting) { generate_some_error_or_status_code_to_say_what_was_wrong(); } (Pardon the 'C'-like constructs, but I think you catch the general idea). The big problem here is, what if data never arrives? Usually, the system designer will know what the worst case arrival time could be, and that value should be incorporated into the design. If no data ever shows up due to some hardware malfunction or improper system configuration, the first loop Awill just quietly wait and hang the system forever until Re-Boot occurs or until data arrives. The second loop detects a problem and signals it to the operator so that something can be done about the problem, and then the program continues with other tasks. >In any case how can a compiler be expected to distinguish the bounded >loop from the unbounded? Do you wish to remove loops entirely? I don't think it is possible for a compiler to distinguish all cases of un-boundedness in a program. It may be able to find possible places where such an event could occur and flag them for the programmer to look at in detail, but there are too many ways to cause unboundedness in any language that I can think of to create a tool that would be able to detect 100% of all possible ways. Removing all looping constructs would obviously be overkill also, due to the usefulness of such things the the uselessness that they would create in a program. What program out there exists (except for all but the most trivial examples) that doesn't need to use a loop to perform? I feel that the best way to protect against a run-away loop is to provide the programmer with a good set of error reporting mechanisms and then specify that all loops that could be unbounded have a check to ensure that such a condition is reported and the program aborts the operation as gracefully as possible. Handling error conditions is (IMHO) one of the toughest things to do correctly when writing a program, but also one of the most necessary. >I'd say many real-time systems have a fervent hope that they will not >terminate until the holocaust of the FINAL POWER DOWN. So logically-infinite >loops are needed. You know things of the sort > > while true do > keep that reactor running I think pretty much every RT program for an embedded system has at least one loop like this in the main routine. The whole trick is to ensure that such loops exist in only desired places. Nothing is more frustrating than watching a piece of very expensive hardware self-destruct because a 23 cent switch failed to signal a stop condition to the software. To paraphrase an advertisment currently running on television: "A radio-telescope drive motor that won't start is a problem, but a radio-telescope drive motor that won't stop......" >I don't really see why loops are any more dangerous in RT. You need to >do more thorough analysis of their behaviour, but that is true for all >RT programming. Non-terminating calculations are not appreciated in any >program. This statement really sums it all up. The only reason a loop can be more dangerous in a RT program is that failure can cause serious injury to very expensive equipment and to people close by. A paranoid design is best, IMHO. The designer should assume that each part will fail at least once during the lifetime of the product, and figure out what the software can do (if anything) to guard against a catastrophic result. >Brendan Mahony | brendan@batserver.cs.uq.oz -dave
yodaiken@chelm.cs.umass.edu (victor yodaiken) (10/01/90)
There is an underlying difference between a loop and an iteration in that
loops can repeat state, while each iteration is different. Standard prog.
languages do not distinguish between the two, but maybe a r.t. language
should. Or maybe we need to distinguish between constructs that compute
mathematical functions e.g., "sum all the bits", and those which manipulate
time, e.g. "wait until x>0" or "strobe x every k ms".