Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!boulder!grunwald
From: grunwald@foobar.colorado.edu (Dirk Grunwald)
Newsgroups: comp.lang.c++
Subject: Re: discrete-event simulation in C++
Message-ID: <25103@boulder.Colorado.EDU>
Date: 23 Aug 90 18:07:29 GMT
References: <2533@ryn.esg.dec.com> <5845@castle.ed.ac.uk> <5605@abaa.UUCP>
Sender: news@boulder.Colorado.EDU
Reply-To: grunwald@foobar.colorado.edu
Followup-To: comp.lang.c++
Organization: University of Colorado at Boulder
Lines: 28
In-reply-to: korsberg@abaa.uucp's message of 22 Aug 90 11:47:46 GMT


The ``awesime-2.0'' library implements threads and a one subclass
implements a SimulationMultiplexor for threads that provides a typical
process-oriented simulation environment. The awesime threads will
eventually be integrated into libg++ (doub, stop me if I lie). It
current works on i386, m68k, ns32k, MIPS, SPARC and m88k. True
parallelism is only current available on the Encore Multimax; it
should be simple to hack for the solbourne (sparc) or sequenet (i386),
but i haven't done it yet.

I'm planning on finding a student to hack a discrete event simulation
environment using this threads package, allowing people to implement
distributed simulation environments as well as simpler global time
systems.

IMHO, DES packages are more efficient than process oriented systems
(POS), but can be more of a pain to set up if they don't match your
model very well. They're more eff. because you don't need to switch
thread context all the time. You can implement it to maintain context
using e..g, one or two words in an object. Thus, you could get decent
performance out of e.g., a SPARC, which is very hard for POS because
of all the register window overhead.

For a ``proper'' DES, you'd only have one thread per physical CPU, and
use those to execute the DES objects. 

Dirk Grunwald -- Univ. of Colorado at Boulder	(grunwald@foobar.colorado.edu)
						(grunwald@boulder.colorado.edu)