Ensuring "random" consistency when using threads?

General Discussion Other

gordoncsa

Ensuring "random" consistency when using threads?

in General Discussion • Other • 1 year ago

In my simulation, I'm using randomSeed to keep the random actions consistent if I wish, so I can have it rerun multiple times while slowly changing one behavior variable.

That solved the problem for the moment, but since I've implemented threads (so it doesn't freeze momentarily while the pathfinding executes), each iteration has become slightly different again (I'm not changing any behavior variables yet).

Without getting into the specifics of my code, has this kind of thing been a problem before? Ensuring that the different random() calls get called in the right order?

Thanks.

Replies(3)

PhiLho

Re: Ensuring "random" consistency when using threads?

1 year ago

Threads are, by definition, non deterministic. They are handled by the system which yields the threads when the CPU and the other programs allow this.
Perhaps a way to be more deterministic is to access the random number generator via a synchronized function. Although it won't ensure a right call order, unless you block a thread until it is its turn to get a number. Not a simple problem.

a__g

Re: Ensuring "random" consistency when using threads?

1 year ago

I think there are ways of ensuring that threads are executed in the "right order" as you say. I've never seen a reason to use it myself though so I can't give you any quick code-paste's - but the idea is to set the Semaphore to "fair"

When fairness is set true, the semaphore guarantees that threads invoking any of the acquire methods are selected to obtain permits in the order in which their invocation of those methods was processed

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Semaphore.html

gordoncsa

Re: Ensuring "random" consistency when using threads?

1 year ago

Thanks, a_g, I'll take a look at that.

I've found a possible workaround in the meantime. None of the random calls actually occur in the pathfinding thread, but instead are used to find a new semi-random destination once the path is done being walked.

So if I give each entity say 10 frames when they start pathfinding before they can start moving again (during which time the pathfinding thread will hopefully finish), it removes the unpredictable factor of when each one will complete.

Top Reply