Platform-Independence and Scheduling In a Multi-Threaded Real-Time Simulation

10 Pages·2001·0.53 MB·English

by  Sugden, Paul P.

AIAA-2001.-4244
PLATFORM-INDEPENDENCE AND SCHEDULING
IN A MULTI-THREADED REAL-TIME SIMULATION
Paul C. Sugden*
Melissa A. Rau *
Unisys Corporation
NASA Langley Research Center
Mail Stop 169
Hampton, VA 23681
P. Sean Kenney:
Systems Development Branch
NASA Langley Research Center
Mail Stop 125B
Hampton VA 23681
code portability and maintainability. While a multi-
Abstract threaded simulation allows a significant increase in the
simulation complexity, it also increases the workload
Aviation research often relies on real-time, pilot-in- of a simulation operator by requiring that the operator
the-loop flight simulation as a means to develop new determine which models run on which thread. To ad-
flight software, flight hardware, or pilot procedures. dress these concerns an object-oriented design was
Often these simulations become so complex that asin- implemented in the NASA Langley Standard Real-
gle processor is incapable of performing the necessary Time Simulation in C++ (LaSRS++) application
computations within a fixed time-step. Threads are an framework. The design provides a portable and main-
elegant means to distribute the computational work- tainable means to use threads and also provides a
load when running on a symmetric multi-processor mechanism to automatically load balance the simula-
machine. However, programming with threads often tion models.
requires operating system specific calls that reduce
i[]troductio[]
' Software Engineer, Member AIAA. Aviation research often relies on real-time, pilot-in-
*Software Engineer. the-loop flight simulation as a means to develop new
Aerospace Engineer, Member A1AA. flight software, flight hardware, or pilot procedures.
Copyright © 2001 by the American Institute of Aero- Concepts involving pilot interaction may require con-
nautics and Astronautics, Inc. No copyright is asserted current simulation of multiple, independent or loosely
in the United States under Title 17, U.S. Code. The coupled simulation models. A single processor may
U.S. Government has aroyalty-free license to exercise not be sufficient to perform all of the necessary com-
all rights under the copyright claimed herein for Gov- putations of these complex flight simulations. A
ernmental purposes. All other rights are reserved by means to alleviate this problem is to distribute the exe-
the copyright owner. cution of independent simulation models among multi-
ple processors. Symmetric multi-processor machines
American Institute of Aeronautics and Astronautics
allowtheindependseimntulatimonodetlosbedistrib- velopeorrusere,xperienscheowthsaetveninasmall-
utedamonegvenltoopsexecutiningparallelE. ach scalseimulatiothni,sprocecsasnbecostlyin,volving
processmoursbteabletocomplettheecomputationesducatteridalandcrrorguesswehseanfeasibdleistri-
ofthemodelasssignetodit beforteheendofthe butionmaynotevcnexist.Amoreeffectivseolution
frame.Thereforthee,numbeorfsimulatiomnodels istoprovidaeutomasticchedulionfgeachmodefol r
thatcanbeexecuteindareal-timmeulti-processoerxecutiboynaparticultahrread.
simulatioisnlimitedbythenumbeorfprocessors
Toaddresthseseissuetsh,eexistindgesigenvolved
availabfloerreal-timueseandbythecomputational
intoanewformthaitsbothportabalendmaintainable
requiremeonftthsesimulatimonodels.
andprovidetshemechanismfosr anautomatic
Traditionamllyu,lti-procescsoomrputearrseusedby schedulianlggorithtmodistribuatesetofsimulation
startinsgeparapterocessoenseachprocessoTrh.e modealscrosasnumboefrthreadssu,chthattheload
processinetserawctitheacohthevriasharemdemory,isasuniformaspossiblTeh.enewdesigbnlendtshe
message-paosrssinogm,eothefrormofinter-procespsre-existinthgreaddesignwith the portability
communica(tIiPoCn)W. hilemulti-prociemspslemen-abstractiounsedin the LaSRS+a+pplication
tationasrefunctionathl,eyarenotoriouscloymplex,framewoforkrotheorperatinsygstesmervices
z.
difficulttomaintaina,ndlimittheuseofpolymor-
While the application of these techniques in the
phismincertaimnodeornbject-orienptreodgramming
langua6g.esMulti-threadseodlutionosn, theother LaSRS++ framework is used for the special purpose of
handa,llowmultipltehreadosfexecutiotonoperate flight simulation, the thread design and the automatic
withinthesamaeddresspsaceel,iminatitnhgeneefdor scheduling algorithm are independent of the purpose of
the application. The design is a simple, user-friendly
IPCsa,ndeliminatirnegstrictioonnstheuseofpoly-
solution for the execution of any sequential, real-time
morphismT.hreadasresupportbeydmosmt odem
operatinsygstemansdtherebeynabtlheedevelopmenaptplication, running on a symmetric multi-processor
architecture, whose iterations can be resolved into two
ofaneleganpt,latform-indepesnodleuntitotnothe
probleomfhowtosimulamteultipvleehiclecsoncur-or more independent sequences of computation.
rently. Design Requirements
Inpreviouwsortkagenerdicesigwnaspresentfeodr A preexisting design for multi-threaded, real-time
theuseofthreadinstheLangleSytandaRrdeal-Timesimulation Iwas extended to be platform independent
SimulatioinnC++(LaSRS+fr+a)mewoornkamulti- and incorporate automatic scheduling of models to
processmoarchineW.hilefunctiontahl,edesighnad processors. The design had the following require-
severashl ortcomingFsir.st,thedesigwnasimple- ments for threads:
mentewdithonlytheIRIXoperatinsygstefmromSili-
1. The design must support a variable number of
conGraphiIcnscorporaintemdindT. hisrestrictethde
threads selected at run-time.
framewotrokonlybeingabletoperformmulti-
2. The design must be portable.
threadoepderatioonnstheIRIXplatformS.econtdh,e
3. The design must provide a mechanism for thread
desigunnnecesstaieridltyhethreacdlassteostheIRIX
synchronization that does not jeopardize real-time
barriearndlockimplementatioTnhsis.couplining-
deadlines.
creastehsedifficultoyfimplementthinegsfeeatureosn
differenptlatformasndmaintainitnhgeframeworkThe scheduling algorithm had the following require-
duringoperatinsgystemupgradeCs.learlaymore ments:
portabalendmaintainadbelesiginsneededT.hede-
1. The algorithm must allow a variable number of
signalsofailedtoprovidaemechanitsomdetermiane
simulation models to be processed on each thread.
feasibsleimulatiomnodedlistributiofonrthenumber
2. The algorithm must automatically distribute inde-
ofthreadasvailabdleuringareal-timseimulatioInf.
pendent components of the workload amongst
thedistributiosnelectioisnlefttothesimulatiodne-
2
American Institute of Aeronautics and Astronautics
available threads in such a way that real-time dary storage access is significantly more costly in
deadlines are not jeopardized. terms of time than access to RAM, a suitable operating
3. The algorithm must recognize if a feasible work- system must provide the capability of locking the text
load distribution does not exist. and data segments of a process into RAM.
A design that met the above requirements was imple- Conventional operating systems for symmetric multi-
mented in the LaSRS++ application framework. Ob- processors perform a task called load balancing. Load
ject-oriented programming techniques were used ex- balancing refers to the migration of processes amongst
tensively to hide implementation details and maximize the processors in such away that the total system load
code reuse. Well-known design patterns were used is distributed evenly across all available processors.
where appropriate to promote simplicity and readabil- Since a real-time thread must never share processor
ity of code, and encapsulate specific platform depend- resources with other standard processes, the operating
encies. The Bridge, Singleton, Factory and Mediator system must provide amechanism for forcing a thread
patterns were used extensively 3. Using the Bridge to run on aparticular processor.
pattern, the implementation of an abstraction can be
By default, the operating system is usually unaware of
changed without affecting clients. The Singleton pat-
multiple threads of execution within an address space,
tern ensures that there is a single, globally accessible
leaving the scheduling of these threads as atask for the
instance of a class. The Factory pattern is aspecializa-
process. This type of thread is commonly referred to
tion of the Singleton pattern that is used to encapsulate
as a process-scope thread. However, for multi-
all platform-dependent, conditional compilation. The
threaded real-time simulation applications, multiple
Mediator pattern is an encapsulation of object interac-
threads must be executing in parallel, which by defini-
tion that promotes loose coupling by preventing ob-
tion is impossible for process-scope threads. The op-
jects from interacting directly.
erating system must provide a mechanism for creating
Operating System Requirements for Real-Time threads that are schedulable by the kernel rather than
from within the process. This type of thread is com-
Inorder to build amulti-threaded, real-time simulation
monly called a system-scope or kernel thread.
for a particular symmetric multi-processor platform
running a general-purpose operating system, the oper- If a general-purpose operating system has all of these
ating system must provide certain capabilities. Tradi- capabilities, it is suitable for multi-threaded, real-time
tional general-purpose time-sharing operating systems simulation. Each thread of such a simulation must be a
schedule processes using apreemptive scheduling pol- system-scope thread within a process that has been
icy. This means that a process is forced to relinquish locked into RAM, set to run on a dedicated processor,
control of the processor once itstime slice has expired with preemptive scheduling disabled.
so that other processes can get processor time. Since
Object-Oriented Approach to Threads
hard real-time deadlines could be jeopardized by pre-
emption, an operating system that can support real- The C++ language does not provide any direct (object-
time simulations must provide a mechanism for dis- oriented) support for multi-threaded programming.
abling the preemptive scheduler on processors re- Two types of classes are required for developing ob-
served for real-time use. ject-oriented, multi-threaded applications. These are
classes that represent threads, and classes representing
Traditional time-sharing operating systems also place
thread synchronization mechanisms. Thread synchro-
the address space of processes in virtual memory. Vir-
nization mechanisms include mutexes and barriers.
tual memory allows the operating system to handle
The mutex is a mechanism that ensures mutually ex-
loads that are more demanding in terms of space than
clusive access to data or to non-thread-safe portions of
the machine's random access memory (RAM) will
code (critical sections) in a multi-threaded process.
allow. This is accomplished by swapping pages of
The barrier provides acollection point for some speci-
RAM in and out of secondary storage. Since secon-
3
American Institute of Aeronautics and Astronautics
l- nie a..c..e...... rThrea-diG-F-
Thread
Iportion of | i_2cpu_i d
_2irnpl--_-_a dIm
_I bddge / q.start0 iAbstract ]_
_join0 _join0 Iimplement°r |
_detach0 -__ _detach0 --4 iportion of /
_cancel0 ' _cancel0 [bridge __
• setRunOn 0 /_i q'setRunOn0 .....................
_getRunOn 0 J , _getRunOn0
q'setS cope() J i q'setScope0
fj "if _
V / J ...... _L-_L-ZZZ_............................... _.......... I
PosixThreadl mpl SprocTh read lmpl
q'inst ance0 _start0 'i%tart0
qT'hdreesaldroyl'hnsptalFnacec0tory _joinO _joinO
• makeThreadl mpl0 _detach 0 _detach()
_cancel 0 _canceK)
_setRunOnO _setRunO no
_getRunOn 0 _getRunOn 0
Factory [_-_ _setScope 0 _. \ 41.setS cx:)pe()
pattern
_!.xPos',x re C°ncrete
iimplementor
_ portion of /
_setRunOn0 ................]......... ibridg e .]
Figure 1Thread Design
fled number of threads of execution, and ensures that Figure I shows a UML class diagram of the LaSRS++
none continue until the specified number of threads thread implementation. When a client constructs a
have arrived. new Thread, ThreadlmplFactory constructs the appro-
priate implementation (Threadlmpl). The specific type
Classes were developed for the LaSRS++ application
of implementation is transparent to the client. The
framework that provide a platform-independent inter-
LaSRS++ design for Barrier and Mutex is analogous
face to thread, mutex, and barrier facilities. For each
to the design for Thread.
of these services, the bridge and factory design pat-
terns were used. The bridge pattern prevents clients of To further increase the maintainability of the thread
thread-related services from being affected by imple- implementation, the interfaces of the thread-related
mentation details. This allows the implementation abstraction classes were structured after the Portable
portion of these classes to be changed without requir- Operating System Interface (POSIX) standard, com-
ing any modification to client components. The fac- monly called pthrcads. Pthreads are currently sup-
tory design pattern encapsulates all platform-specific ported under several variants of the UNIX operating
and build-option-determined conditional compilation. system including Solaris, Digital UNIX, IRIX, and
This significantly improves the portability and main- Linux 4. As a result, the use of pthreads allows us to
tainability of the LaSRS++ framework code. build on any of these platforms using the
4
American Institute of Aeronautics and Astronautics
PosixThreadlmpl as the concrete implementation por- may not be guaranteed to resume execution within an
tion of the bridge. This source-code portability is acceptable amount of time to meet a real-time dead-
beneficial in an environment of potentially frequent line. The alternative is to implement a spin-loop bar-
architecture changes 8, rier mechanism. In this barrier, aprimary thread waits
at the barrier for all remaining threads to arrive. As
A requirement of the multi-threaded simulation uncov-
each thread arrives, it locks itself and waits in a spin-
ers a deficiency in the POSIX standard. There is noth-
loop conditioned on the value of that lock. Once all
ing in the POSIX application programming interface
threads have arrived, the primary thread releases the
(API) for specifying a particular processor on which a
lock for each remaining thread, and all threads may
thread must run. This eliminates the possibility of
continue.
constructing a completely platform-independent con-
crete thread implementation for multi-threaded, real- Schedulin_ Algorithm
time applications. A system-scope pthread may be
Efficient thread synchronization alone does not
scheduled on a specific processor for its lifetime, but
guarantee that real-time deadlines will be met. The
the call to do this is platform-specific. However, due
computational load must be balanced across the
to the use of the factory and bridge design patterns, the
processors such that no deadlines are missed during
work required to implement platform-specific pthreads
real-time execution. Before any automatic scheduling
is minimal. The PosixThreadlmpl class has a virtual
assignments can be made, an approximation for the
method setRunOnO that takes the processor number as
maximum execution time of each independent job
an argument. To create a pthread that will run success-
must be determined. Assuming no apriori knowledge
fully on the IRIX operating system, a class named
of the job execution times, the following algorithm is
IrixPosixThreadlmpl was created. This class inherits
used to accomplish this task in as efficient a manner as
from PosixThreadlmpl and overrides the setRunOnO
possible.
method with the IRIX-specific system call for running
athread on a given processor. In this way, the reuse of 1. Jobs are randomly distributed across all real-time
the existing thread classes is maximized, thus minimiz- simulation threads.
ing the work required for implementing platform-
2. Each thread performs any necessary initialization
specific thread models. for alljobs assigned to its processor.
Real-Time Thread Synchronization 3. Each thread performs its jobs a fixed number of
While each thread in a multi-threaded real-time simu- times, tracking the maximum execution time of
each. It is assumed that the observed maximum is
lation is operating on independent tasks, there is often
some portion of the event loop that cannot be executed a good estimate.
before all threads have completed a certain portion of
Once this phase has been completed, the timing infor-
their task. An example of this is computation of rela-
mation can be used as input to one of several load-
tive geometry between simulation models Regardless balancing algorithms that attempt to find a valid distri-
of how relative geometry computations are distributed,
bution of jobs. The load-balancing problem that must
the state of all models must have been updated before be solved can be stated as follows:
any of these computations can take place. A barrier
mechanism is used to implement this sort of rendez- Let P= {p_, p2.... pn} be the set ofn processors and
vous. J = {JJ,J2.... j,,} be the set of m jobs with associated
compute times C = {el, c2.... c,,}. Let L ={6,6....
Operating systems supporting multi-threaded programs
l,} be the total compute time on each processor, and let
also support barrier mechanisms. Programs that are
T be the period of a real-time iteration. Determine a
not subject to strict real-time deadlines should gener-
ally use the operating system supplied barrier facility. mapping f :J ---> P such that:
However, if a thread blocks on a barrier system call, it
5
American Institute of Aeronautics and Astronautics
PositionalModel
I Thread IdoOgerat eCalc 0
_propag ateSt ateO
_profileO
_getM ax'l] me()
........ ':_ _ I multimap<cpu id, PositionalModel> 1
!_7- L_-_.____ ............................. _,,_-')......
___ [ --%_verse
SimControl
........._ _cpu_id L_-............... _j _profileModels(cpu id)
--. v_ ...... ____4-._ /] _balanceLoad0
41)synchronize0 11
_execute0 _doOperate(cpu id)
| ;cute()_ , • . ._ ,
' propagateMooe stcpu_id)
Figure 2 Relationships Between LaSRS++ Core Classes
The computational requirements of this algorithm do
1. _"_._=, /, _''" is minimized not jeopardize real-time deadlines because the algo-
I m c l2
rithm is initially executed prior to running the simula-
tion, and may be repeated at non-critical points of exe-
2. VI;_L,I t<T
cution after starting (e.g., in a RESET mode). Within
larger scale simulations where faster load-balancing
Where lj =_ cj If(J)=i.
algorithms are desirable, any algorithm may be substi-
tuted. Much research has been done with various load-
These requirements ensure that the workload is bal-
balancing techniques, such that an effective algorithm
anced as evenly across the processors as possible, and
can be applied within any arena.
that no processor is overloaded such that deadlines are
missed. This is under the assumption that it is possible Application of these Techniques to LaSRS++
for the given workload to be executed by the processor
Both the platform-independent thread abstraction and
set.
the load-balancing algorithm presented above were
While this problem is NP-complete 9,an algorithm was incorporated into the LaSRS++ framework. The rela-
developed that yields near-optimal solutions in a rea- tionships between various objects that are central to
sonable amount of time. Jobs are sorted by non- the framework are depicted in figure 2. The sequence
increasing execution time. Starting with the largest of execution, from construction of certain core objects
job, each job is assigned to the processor that is cur- to synchronous real-time execution, is depicted in fig-
rently supporting the smallest workload. If ajob can- ure 3.
not be placed, it is assumed that the current workload
cannot be supported in real-time by the given proces-
sor set.
6
American Institute of Aeronautics and Astronautics
i '"_''0
L__
tScopa{SY_M }
.°__,-tialtl me-cPu)
---->1
°oo,.r.t.,,od0l o I " \
propagaleMod I=(cpu id)
}
synchronize i
i Join
i
Figure 3 Core LaSRS++ Sequence Diagram
After being launched, the LaSRS++ simulation process processor, the process constructs one system-scope
locks the segments of its address space into RAM; sets thread and starts it on this processor. These threads
its priority to the highest level available on the system; each begin execution in a function that constructs and
and isolates, restricts, and disables preemptive sched- executes a FlightSim object. At construction time, the
uling on each available processor. For each dedicated
7
American Institute of Aeronautics and Astronautics
FlightSim object is given the processor number on PositionalModels associated with the specified proces-
which the constructing thread is running. sor are affected. This allows multiple FlightSim ob-
jects to cause the Universe to modify disjoint subsets
In the LaSRS++ framework, the real-time simulation
of PositionalModels in parallel.
event loop is defined by the FlightSim executeO
method. Construction and execution of multiple Among Universe's methods are profileModels O,
FlightSim objects by separate Threads results in multi- doOperateO, and propagateModelsO. ProfileModelsO
ple simulation event loops executing in parallel. The is used by FlightSim to execute models in order to gain
event loop consists of several distinct phases, some of an estimate of the maximum amount of compute time
which may not begin until all computations from the that each will takc. This information is required to
previous phase are complete (i.e. updating states of complete the load-balancing operation. DoOperateO
positional models must have been completed before is used by FlightSim to update the outputs (e.g., forces
calculation of relative geometry between models can and moments) of a model during synchronous real-
begin). Each such phase begins with acall to SimCon- time. PropagateModelsO is used by FlightSim to inte-
trol::synchronizeO. This method is an implementation grate a simulation object's state and to compute out-
of a spin-loop barrier, as previously discussed, that puts from the new state that belong to the next frame.
will not return until it has been called by all simulation
After the simulation process has been constructed and
threads. This ensures that all FlightSim objects are
initialized, the workload is profiled and balanced
executing the same portion of the event loop at the
across the available processors. To do this, the Uni-
same time.
verse randomly associates an equal number of Posi-
While FlightSim objects represent the encapsulation of tionalModels with each available real-time processor.
the periodic sequence of events in LaSRS++, Universe The simulation is initially in PROFILE mode. In this
is the maintainer of the simulation model data. All mode, FlightSirn objects call the Universe's pro-
simulation model objects are derived from Position- fileModels() method. Since there is aFlightSim object
alModel, and are contained within the Universe single- for each real-time processor, this results in all models
ton. Universe mediates between PositionalModels and getting profiled. The main simulation thread then calls
all other components of the simulation framework, the Universe balanceLoadO method. Using the algo-
meaning that a PositionalModel may only be modified rithm discussed in the previous section, the Universe
through action taken by the Universe. modifies the mapping of PositionalModels to proces-
sors within its multimap such that the load is as evenly
To manage the active models during execution, the
distributed as possible. If afeasible workload distribu-
Universe has a member data structure that maps each
tion does not exist, the user is informed, and the simu-
model to the processor on which it is to be executed.
lation will not be allowed to transition to the real-time
The structure is a multimap container from the C++
OPERATE mode.
Standard Template Library (STL) 5, The multimap
maintains asorted list of key and value pairs. The pairs After the simulation has transitioned into the synchro-
stored in the multimap contained by Universe are the nous real-time OPERATE mode, the FlightSim objects
processor identifiers and PositionalModel objects. perform the following periodic sequence of steps:
Use of the STL provides a portable and robust data
I. SimControl: :synchronizeO
structure, which has been thoroughly tested and whose
interface is well defined. 2. Universe: :doOperateO
Within the multimap, PositionalModels are found us- 3. SimControl: :svnchronize 0
ing the processor identifier as the search key. Corre-
4. Universe:.'propagateModels 0
spondingly, all of the Universe's methods that act on
PositionalModels take a processor number as an ar- 5. SimControl: :synchronizeO
gument. When one of these methods is called, only the 6. Universe: :relativeGeometry 0
American Institute of Aeronautics and Astronautics
Model Distribution
B Before Scheduling FlAtter Scheduling]
8O
69
"_ 60
37
_ 4o
21
2o
Z
0
2
CPU Number
Figure 4 Workload Distribution
Experimental Results multiple threads, this workload could not be executed
within real-time constraints.
The capabilities of the multi-threaded simulation and
the scheduling algorithm were tested with a mixed Figures 4 and 5 demonstrate the effectiveness of the
workload of transport aircraft, fighters, and missiles. load-balancing algorithm on the given workload. Prior
The models and their associated maximum compute to balancing, the number of models for each processor
times are presented in Table 1. is similar, but the workload on the first processor is
approaching the upper bound of 20 ms. A slight varia-
Model Type Cost (ms)
tion in the model computations or the system perform-
B757 4.35 ms ance in this configuration could result in a frame over-
run - an unacceptable occurrence in a real-time
F/A-18E 6.59 ms
simulation. The load-balancing algorithm then
F-I 5A 0.99 ms successfully schedules the models in a configuration
that ensures that the load on all processors is well
F-16A 0.87 ms
within the boundaries of the real-time deadlines.
Launch Envelope Missile 0.01 ms
Concluding Remarks
Table 1 Positional Models and Associated Costs The design has allowed the framework to be compiled
The LaSRS++ real-time simulation runs on an SGI and run on the SGI and the Sun platforms, and it will
be ported to the Linux and Win2000 platforms in the
Onyx with eight processors, three of which are avail-
near future. Moving the framework to anew platform
able for the parallel execution of simulation threads.
only requires the development of several implementa-
The simulation is run at a frame rate of 50 Hz, corre-
tion classes that can be unit tested before use with the
sponding to a 20 ms frame time. To demonstrate the
framework.
effectiveness of the use of multiple threads and the
load-balancing algorithm, a workload was created The abstractions found in the thread design make the
comprised of three B757s, two F/A-18Es, 10 F-15As, framework easy to maintain. Any modifications to the
and 10 F-16As. Each fighter is equipped with four operating system that might require changes to thread,
launch envelope missiles. Note that without the use of barrier or lock classes would require changes only to a
9
American Institute of Aeronautics and Astronautics
Workload Distribution
11Before Scheduling [] After Scheduling
25.0000
19.9780 :
_'_ 20.0000 13,95815"2874
_) 15.0000
E
I,- 10.0000
t_ 5.0000
0.0000
2
CPU Number
Figure 5 Model Distribution
platform specific implementation. The modifications
could then be verified using the unit test for the modi- [4] David R. Butenhof. Programming with POSIX
fied class and would not require extensive re-testing of Threads. Addison-Wesley Publishing Company,
the framework itself. Reading, Massachusetts, 1997.
The scheduling algorithm alleviates unnecessary bur-
[5]Nicolai M. Josuttis. The C++ Standard Library: A
den on the simulation operator by providing an effec-
Tutorial and Reference. Addison-Wesley Pub-
tive solution to the load distribution problem.
lishing Company, Reading, Massachusetts, 1999.
Although the design presented in this paper was origi-
nally designed to support flight simulation at NASA [6] Michael Madden, et al. Constructing a Multiple-
Langley Research Center, the design could be used in Vehicle, Multiple-CPU Using Object-Oriented
any object-oriented framework to more effectively C++. Paper Number AIAA-98-4530, August,
utilize the capabilities of symmetric multi-processor 1998.
machines.
Biblio2ra_hv [7] Richard A. Leslie, et al. LaSRS++ An Object-
Oriented Framework for Real-Time Simulation of
[1] David Geyer. The Use of Multiple Threads in an
Aircraft. Paper Number AIAA-98-4529, August,
Object Oriented Real-Time Simulation, Paper 1998.
Number AIAA 99-4338, August, 1999.
[8] Bill O. Gallmeister. POS1X.4: Programming for
[2] P. Sean Kenney, et al. Using Abstraction to Create
the Real World. O'Reilly & Associates, Inc. Se-
a Portable Object-Oriented Simulation, Paper
bastopol, Califi)rnia, 1995.
Number AIAA 99-4340, August, 1999.
[9] Christos H. Papadimitriou. Computational Com-
[3] Gamma E., Helm R., Johnson R., Vlissides J. De-
plexity. Addison-Wesley Publishing Company,
sign Patterns: Elements of Reusable Object-
Reading, Massachusetts, 1994.
Oriented Software. Addison-Wesley, Reading,
Massachusetts, 1995.
10
American Institute of Aeronautics and Astronautics