« Last post by cappe on Today at 03:01:18 pm »
« Last post by cappe on Today at 03:01:18 pm »
« Last post by Zoran on Today at 02:50:02 pm »
Okay, I voted too, but... It seems that no other projects has got any vote so far.
You missed the point that all the state variables are threadvar.emm... maybe no.
I'm not speaking of random being non-threadsafe. I'm speaking of randomization being non-treadsafe (maybe I'm using a wrong terminology).
Saying that I mean that if we start 2 simultaneous threads and randomize the random - simultaneously - system.Random will return equal random seeds.
And therefore 2 identical random sequences will be spawned.
(yes, it has been addressed many times, that re-using Randomize actually harms random and should be used only once per program)
Yes, I'm thinking from game point of view
I'm generating a maze. I can generate 8 mazes simultaneously on my 8-core CPU.
I create (almost simultaneously) 8 generation threads each initializing its own random seed.
If I won't make precautions and use system.Randomize (or directly gettickcount) I'll get 8 identical mazes instead of 8 different mazes.
Moreover, I count that system.random following a deterministic pseudo-random sequence.
If I start a threaded random I'll have a background call to system.Randomize which will break the deterministic random sequence.
E.g. if I want to have a one thread that uses system.Random with a predefined seed, and my threaded random will run (randomize) in background. I'll get different results with the same predefined seed. In other words, I count that if I have a seed "123" it should generate identical maze. But once launched the thread I find myself with a different mazes with nearly impossible to get the reason that caused it.
One more point is that when I launch the computer, gettickcount is zero. E.g. let's imagine a situation. I come home. I launch the computer to play my maze. Eventually I find myself in the very same maze I've been playing yesterday! Why? Because gettickcount while has a step of less than a second, but updates only 64 times per second, therefore, if I launch the game at the very same second after start-up I get only 64 variants for my mazes, one minute gives less than 4000 variants, which is while large, but still can repeat by accident.
And if you look up Marsaglia in our wiki you will see I intend to also add these in the same way..Missed the update of your post. I've read this article, but I should look closer.
You missed the point that all the state variables are threadvar. That is enough to make it threadsafe... The rest of the code does not matter.
And if you look up Marsaglia in our wiki you will see I intend to also add these in the same way..
I would highly appreciate your opinion about the attached code, btw.I'll try to have a closer look today evening (thou, I'm really not an experienced programmer ).
At first glance: randomization is not thread-safe.
I.e. if one randomizes the generator in 8 semi-simultaneous threads, he'll get exactly the same random seeds (what is not really expected of threaded random generation).
I've found three sources of semi-random seed: current tickcount (as system.Randomize does, however, once one calls this function it results in an abrupt change in system's random seed (which might be unexpected if not documented properly) plus the "number of random sequences" is very limited e.g. regularly approx ~200 000 of possible high(longword) in xorshift or much more in Mersenne Twister), current date&time (yes, they are synchronous with tickcount, but still semi-independent, because they count from two different non-linked events) and memory allocation (e.g. trying to get address of a pointer to local variable, which is guaranteed to be different for different threads and has some extent of randomness of its own). Of course, one may just read /dev/urandom on Linux (maybe, with more caution on all *nix platforms) for much better results.
« Last post by Thaddy on Today at 02:00:32 pm »
You can edit it as solved..
« Last post by egsuh on Today at 01:47:52 pm »
Sorry. I made errors myself. Edit..Post works fine. Just I cannot remove the previous post.
Tnx for re-reading, and understanding the matter! I would highly appreciate your opinion about the attached code, btw.
This is all about randoms in the scientific sense (repeatable random sequences) , not in a gaming sense.Oops. Sorry I've been unattentive - I didn't see who authored the first post . I've seen your article on random generation I've thought it was just another "general" question.
@ Eugene Loza
My purpose is to stick with standards - I happen to need this for statistics - , but still have a thread safe implementation if Multi-threaded..
To see what I mean I have attached what I am proposing to add to the rtl (this is not complete, I am re-defining everything into a common style):
This already works just like
a) Free Pascal if required
b) Delphi if required
c) (Not here, but in the codebase) C and C++ standards compatibility.
Essentially, eventually I would like to have pluggable Randoms, like in C++11 and higher.
The unit also shows that data that relies on a specific pseudo random number generator (like Delphi's) can be processed by FPC if the source and seed are known.
This is all about randoms in the scientific sense (repeatable random sequences, A.K.A PRNG's) , not in a gaming sense.