Home/ Questions/Q 1005071
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T08:14:05+00:00

I am writing a numerical program that should be somewhat fast, and is also

  • 0

I am writing a numerical program that should be somewhat fast, and is also multithreaded. I have a class that represents a number, and I want to use in it a random number generator. Now, I don’t really require my RNG to be a true RNG, I just need it to generate integers with even distribution between 0 and NMAX.

So I have this in my class:

// use just an int here and forget about multithreading.
static uint32 rand = NMAX/4; 
// this will be called multithreadedly
static uint32 GetRand() { return rand = ( rand + 1 ) % NMAX; }

Now, in a single threaded world, this is totally fine for my purposes.

Since this is multithreaded, I’m assuming that the only possible bad thing that could happen is that occasionally (like <1% of the time) the update gets dropped. Meaning two threads read rand, update it in a register, return the updated value, and then write it, twice, with the same value. This is totally fine.

My question is could anything worse than that happen? I’m totally fine with each thread using its own rand variable but that’s just a huge pain to make happen. What I definitely can’t do is make it so that each instance of the class uses its own rand variable, as that would use way too much memory.

UPDATE:

So, why do I want to do this? Full story is its a floating point class that uses 1 or 2 bytes. So it has to be fast and such, and this just seems the best way. In fact I think I’ll update it from ( rand + 1 ) % NMAX to something like ( rand + [some prime] ) % NMAX since it seems to work better. This is an example of one of those cases where a more robust solution would require more code, make things less generic and more dependency ridden, make code less clear and easier to break, and all for the idea that “proper synchronization should be used”.

Mostly I’m worried of some weird optimization that the compiler might do, so that an update to rand is not just dropped, but rand becomes total garbage. Now that I think about it though, even that would be okay (the way this number is used), since the next use of GetRand would %NMAX it anyway, the error would only cause at most one use of GetRand to be outside the given range of [0,NMAX). Thanks for any answers.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If two threads call GetRand at the same time, the classic unsynchronized error may happen. For example, rand = 10. After two threads call GetRand, rand is expected to be 12, but actually it may be 11. If this OK for you, you can leave this code without changes. But I think it is better to use synchronization, because without it both the code and its result look a bit strange. Another programming can think that is is bug.

    Edit.

    rand = ( rand + 1 ) % NMAX;

    Worst case: two or more threads read the same rand variable rand from the memory. Each thread locally makes calculation ( rand + 1 ) % NMAX. Then all threads put the same result back to the memory. This doesn’t corrupt the rand variable value, this doesn’t cause this variable to be out of scope and number generator will continue to compute valid numbers.

    • 0