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.1 required=5.0 tests=BAYES_40,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!MITRE-BEDFORD.ARPA!sdl
From: sdl@MITRE-BEDFORD.ARPA.UUCP
Newsgroups: comp.lang.ada
Subject: Re: Tasks and Simulation
Message-ID: <8701260236.AA00669@mitre-bedford.ARPA>
Date: Sun, 25-Jan-87 21:36:16 EST
Article-I.D.: mitre-be.8701260236.AA00669
Posted: Sun Jan 25 21:36:16 1987
Date-Received: Tue, 3-Feb-87 01:36:17 EST
References: <469@cod.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>


>  We are considering using Ada to write a non-real-time simulation of
>  combat engagements....
>  
>  The problem is to model the passing of real-world time while
>  maintaining the independence of the tasks....
>  
>  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.

All true!  A number of Ada hackers (myself included) have independently
found a reasonable solution to this problem.

Assume that simulation processes are implemented by Ada tasks.
Simulated time is not allowed to "pass" until all of the processes
have "reported in" that they have no more events to schedule (so they
can all be suspended).  The simulation executive task (in control of
advancing simulated time) simply keeps a count of how many simulation
process tasks have reported in; it suspends each in turn.  Once all of
them have been suspended, the executive can then advance time to the
next event.  Whichever process task is supposed to deal with that
event is then "reawakened" by the simulation executive, and so on.
Voila!

This, of course, requires that the process tasks be reactivated in an
order different from the order in which they were suspended.  To do
this, "agent" tasks (visible to and controllable by the simulation
executive) are used as intermediaries.

Cf: "Implications of the Ada Environment for Simulation Studies," P.
Friel and S. Sheppard, Proceedings of the 1984 Winter Simulation
Conference.  

The authors are from Texas A & M University Comp. Sci. department,
which has done much fine research (& written many papers) on the
subjects of simulation in Ada, distributed simulation, etc.

BTW, Dr. S. Sheppard and Dr. K. Murray emailed me the Ada source code
of their simulation system.  It appears to work OK.  I believe it
would be a fine submittal to the Ada Repository.  (Are you listening,
by any chance?)


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730
(617)271-7753

ARPA:  sdl@mitre-bedford
UUCP:  ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl