7

Is this possible to run multithreaded Java application in a deterministic fashion? I mean to have always the same thread switching in two different runs of my application.

Reason for that is to run simulation in exactly the same conditions in every run.

Similar case is when one gives some arbitrary seed when using random number generator to obtain always the same "random" sequence.

Steve Kuo
  • 61,876
  • 75
  • 195
  • 257
sZpak
  • 247
  • 10
  • 1
    Thread scheduling is controlled by the OS, not Java. – Andy Turner Apr 14 '16 at 15:07
  • If you synchronized your code carefully enough and you only depend on input available up front, it should always appear to run the same way. (Or to turn it around, if outcomes depend on the specific timing of each run, you haven't synchronized your code well enough.) Depending on what you really need you could also try a real-time implementation of the Java VM. – biziclop Apr 14 '16 at 15:16
  • 1
    @biziclop, If your program is so thoroughly synchronized, chances are, you've lost at least some of the benefits of using multiple threads. – Solomon Slow Apr 14 '16 at 16:55
  • 2
    One idea that's been floating around for quite some time (but I don't know how much mind share it's getting) is to use a virtualized environment that forces particular serializations of a multi-threaded execution. The usual purpose is to _test_ a multi-threaded algorithm (i.e., to prove that all possible serializations will behave correctly.) Only example I can think of right now is https://github.com/google/thread-weaver ---written a few years back by some folks at Google. I don't know if it's any good, or what it's any good _at_, but it might be worth a look. – Solomon Slow Apr 14 '16 at 17:03
  • @jameslarge Almost certainly, yes. – biziclop Apr 14 '16 at 17:35

3 Answers3

4

I am not aware of any practical way to do this.

In theory, it would be possible to implement a bytecode interpreter with an entirely deterministic behavior under certain assumptions1. You would need to simulate the multiple threads by implementing the threads and the thread scheduling entirely in software and using a single native thread.


1 - For example, no I/O, and no use of the system clock.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • You'd also potentially have to implement GC. – biziclop Apr 14 '16 at 15:19
  • @biziclop - Maybe not. The only GC-related sources of non-determinism you would need to worry about are identity hashcodes based on memory addresses, and finalization. Both could be dealt with, I think. – Stephen C Apr 15 '16 at 12:37
4

No it is not possible (other than to simulate it yourself) to use multiple threads interleaving in the same way each time around. Threads are not designed to do that.

If you want deterministic results, don't use threads.

OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
0

As quoted by OldCurmudgeon, it's not possible with multi threading.

If you decide to use single Thread, I prefer newSingleThreadExecutor to normal Thread due to flexibility and advantages of newSingleThreadExecutor

Use

newSingleThreadExecutor from Executors

public static ExecutorService newSingleThreadExecutor()

Creates an Executor that uses a single worker thread operating off an unbounded queue. (Note however that if this single thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks.)

Tasks are guaranteed to execute sequentially, and no more than one task will be active at any given time. Unlike the otherwise equivalent newFixedThreadPool(1) the returned executor is guaranteed not to be reconfigurable to use additional threads.

Related SE questions:

Difference between Executors.newFixedThreadPool(1) and Executors.newSingleThreadExecutor()

ExecutorService vs Casual Thread Spawner

Community
  • 1
  • 1
Ravindra babu
  • 37,698
  • 11
  • 250
  • 211