How to slow down a worker thread doing some scientific calculations?

[d_stranz]

Hope you don't mind us beating up on you but you can still accomplish what you want without inserting delays into the simulation.

If you can currently pause your simulation, change parameters, and then resume it again, I assume you have some concept of "current state of the simulation using parameters {x}".

So, back to my proposal where the simulation runs at full speed to completion and saves a list of results: A relatively easy way to implement the pause / change / resume feature would be to not only output the intermediate results at each time step, but also output whatever state variables / parameter values there are at that step. When the user pauses the playback, edits parameters, and resumes, you reload the simulation with the current state values and new parameters, discard the rest of the results list, then let the simulation run to completion from that point forward.

Another benefit: If simulation always runs to completion, you have the option of saving the whole list to a file. The user can then step backwards to some point, change parameters, and let it run again. Now you have a way to directly compare two versions of the simulation side-by-side to see the effect of the parameter change. Or you can reload a saved simulation to study it again, without having to recompute it. If you really decouple the results viewing from the results generation and save some version information in the results, now you have a way to compare the effects of algorithmic changes as well as parameter changes.

[agarny]

Hope you don't mind us beating up on you but you can still accomplish what you want without inserting delays into the simulation.

If you can currently pause your simulation, change parameters, and then resume it again, I assume you have some concept of "current state of the simulation using parameters {x}".

So, back to my proposal where the simulation runs at full speed to completion and saves a list of results: A relatively easy way to implement the pause / change / resume feature would be to not only output the intermediate results at each time step, but also output whatever state variables / parameter values there are at that step. When the user pauses the playback, edits parameters, and resumes, you reload the simulation with the current state values and new parameters, discard the rest of the results list, then let the simulation run to completion from that point forward.

Another benefit: If simulation always runs to completion, you have the option of saving the whole list to a file. The user can then step backwards to some point, change parameters, and let it run again. Now you have a way to directly compare two versions of the simulation side-by-side to see the effect of the parameter change. Or you can reload a saved simulation to study it again, without having to recompute it. If you really decouple the results viewing from the results generation and save some version information in the results, now you have a way to compare the effects of algorithmic changes as well as parameter changes.

Thanks a lot d_stranz, you make some good points. I particularly like the possible benefit of comparing two versions of a simulation side-by-side. Possible because it assumes that the 'default' simulation would have time to finish, for which there is no guarantee whatsoever.

Anyway, I have to be pragmatic. My simulation code has been stable for months. Yet, from what I can tell, to implement your suggestion would require quite a bit of work on my end. So, the simplest solution for me would be to slow down my worker thread: minimal work on my end, no additional testing required, etc.

So... this is what I did yesterday afternoon. I simply added a loop that does nothing for a given number of times (to make the worker thread more or less slow). I genuinely wish there was a better way to slow down my worker thread, but at least it was very simple to implement, didn't require me having to rework my GUI thread, retest things, etc. and, more importantly, it does exactly what I want. Sure, a loop that does nothing will use the CPU for... nothing, but then again it's a worker thread, so I am 'fine' with it being always busy while it's actually running a simulation.