Here's a further revised Schedule for anyone interested. Totally experimental -- indeed, basically untested. It's been modified in the following way. - Any thread can now schedule things on the schedule at any time, even while schedule.step() is running. - Any thread can now call reset() or simstate.kill(), but be advised that other threads could theoretically add new things on the schedule even after it's been reset, thus nullifying the point of reset() or kill(). - Any thread can call time() (or a new identical method, getTime()) or getSteps() - schedule.step() explicitly looks for reentrancy and denies it - I've deleted the numOrders constructor. It's time. - I've deleted the throwsExceptions option. A bit faster and cleaner. It's time. I do this by employing two locks: (1) the Schedule itself, whose synchronization controls access to step() to prevent some race conditions, and (2) an internal lock which controls access to the time, steps, shuffling parameter, and heap. Using this second lock allows some finer control over critical regions and thus makes possible the "any thread" stuff in the bullets above. It doesn't look much slower, so I may keep it. But I won't add it to CVS without some major testing. Anyone up for it? To be threadsafe, AsynchronousSteppables and ParallelSequence still shouldn't call reset() or simstate.kill(), but rather should schedule a Steppable which calls simstate.kill().