proper way to "reset" the pulse engine

I’m using the Java interface (Java 11, Windows 10, 64-bit), and my application can run multiple scenarios (e.g., open a scenario and run it, then open a different scenario and run that, etc.).

My current approach is to throw away the PulseEngine object and create a new one (specifically, I call PulseEngine.cleanUp(), and then let Java garbage collection take it from there). This works fine if the engine is not running. However, if the engine is in the middle of advancing time, then the jvm crashes. I don’t see a way to cancel a run.

Is my approach to “resetting” valid, or should I be trying to reuse the engine? How can I cancel an in-progress run, or at least wait for it to complete? (Cancelling would be better, because it is possible that the run is long.)

Can you describe what an in progress run means for you?

Generally, I suggest calling the AdvanceTime with a small time step from Java, in a loop in Java
So you can implement your own cancel to break out of that loop.

Are you calling AdvanceTime with something like 30s or more worths of time advancement?
And you would like to cancel after say, 5s of processing that 30s?

Are you using this class method to run your scenario?

I’m running in 1 second intervals, but I have another thread that is generating these. If the answer is that I need to figure out how to coordinate my threads such that Pulse doesn’t have to be interruptible, then I can do that. I was just hoping there was some built-in way.

I am not using that class method. Sorry I wasn’t clear – my application has its own notion of scenario, some of which has to do with Pulse and some that doesn’t. So I’m running by calling advanceTime(1000) in a loop on a separate thread, which I can pause/resume at will. The issue is just around when I’m loading a new scenario – I call pause which causes the loop to stop calling advanceTime, but then it runs ahead and tries to call cleanUp while the pulse engine is still running from the last call. And I don’t see a built-in way to get that information (I can work something out in my own application).

From a Pulse perspective, I could potentially put an isRunning flag in this loop that would be true while that loop is running

But if you are providing a time of 1s to this this AdvanceTime call, then that flag is going to be going off and on quite frequently and not of much use to you.

If I am understanding your application, The only thing I could think you I could add in Pulse, would be a flag that basically tells Pulse to ignore any more AdvanceTime calls you send it until you load up another state file, which does not seem like a good idea.

I think it is best you coordinate your threads to all fully complete on a cancel and then start them back up with a new state.

As for the other part of your question, you do not need to deallocate the Pulse Engine, you can just call the serializeFromFile/State method on the same engine (assuming no other thread is calling advance while the load is occurring). The engine will properly clear state from the previous run when it loads the new state.

The clean up basically deletes the memory, and the instantiation of the PulseEngine class allocates a new C++ engine. So that is the safest way to ensure a clean engine, but Pulse was designed so it is perfectly acceptable to have 1 instance of a PulseEngine to execute multiple Scenarios.

Ok, that all makes sense. I think the thing that would be nice on the pulse side is just to not crash the jvm if cleanUp() is called while advanceTime() is executing. The right thing may be to engineer an application such that that never happens (which is what I’m going to do), but an error message without a crash is much nicer than taking down the whole jvm :slight_smile:

It would be pretty a daunting effort to harden Pulse to all the possible multi-threaded race conditions user could introduce (What about asynchronous calls to pullData, getAssessment, etc… I would just have to put mutexs and flags everywhere to guard against that)

That would also take all the fun out of multi-threaded programming :slight_smile:

Understood :slight_smile: