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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!sdcsvax!nosc!cod!dennis From: dennis@cod.UUCP (Dennis Cottel) Newsgroups: comp.lang.ada Subject: Tasks and Simulation Message-ID: <469@cod.UUCP> Date: Thu, 22-Jan-87 16:51:04 EST Article-I.D.: cod.469 Posted: Thu Jan 22 16:51:04 1987 Date-Received: Fri, 23-Jan-87 21:07:05 EST Organization: Naval Ocean Systems Center, San Diego List-Id: We are considering using Ada to write a non-real-time simulation of combat engagements. It would seem a perfect application of object-oriented design to use Ada tasks to model the independently operating combatants, and in fact, to use tasks to model independent functions within the weapons and platforms. The problem is to model the passing of real-world time while maintaining the independence of the tasks. For instance, the combat control logic may want to wait for either an enemy detection, or for five minutes to pass before making a maneuver. Ada provides a method for waiting for a period of real time to pass, but this won't work for a simulation because modeled time may proceed either faster or slower than real time. The obvious answer is to have a 'clock' task(s) which accepts requests from other tasks to wait until a given modeled time arrives, then releases the waiting tasks when modeled time reaches that value. However, the clock can only advance the modeled time to T1 when it knows that no other task is going to make a request to be released at a time T2 < T1. This essentially means that the clock process has to divine that all other tasks are quiescent before advancing the modeled time. This is where I'm stuck. It would presumably work to make the clock task a lower priority than all other tasks, but priorities are not a part of the Ada definition. All other solutions I can think of require kludgy calls throughout all the tasks. This violates the original reason for taking a tasking approach, namely, that the design of each independent object should not need to know anything about timing in other objects, or the timing implementation. If there were a straightforward way to deal with this issue, the resulting program should be quite clear and easy to understand. However, the Ada books that I have seen don't deal with this particular problem. Are there books or journals that do? Anyone have advice or suggestions? How about actual experience writing code? Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 225-2406 dennis@NOSC.MIL sdcsvax!noscvax!dennis