Categories
c# numbers random

Is C# Random Number Generator thread safe?

98

Is C#’s Random.Next() method thread safe?

2

  • 1

    “Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.” (from the docs on System.Random). [OK, to be fair: the single most common problem with pseudo-random numbers that people seem to have is also explained there and they still keep asking]

    – Joey

    Jun 16, 2010 at 8:43


  • 4

    I believe you can now use Random.Shared property as of .NET 6 for a thread-safe Random instance

    Dec 21, 2021 at 4:37

35

There’s nothing special done in the Next method to achieve thread safety. However, it’s an instance method. If you don’t share instances of Random across different threads, you don’t have to worry about state corruption within an instance. Do not use a single instance of Random across different threads without holding an exclusive lock of some sort.

Jon Skeet has a couple nice posts on this subject:

StaticRandom
Revisiting randomness

As noted by some commentators, there is another potential problem in using different instances of Random that are thread-exclusive, but are seeded identically, and therefore induce the identical sequences of pseudorandom numbers, because they may be created at the same time or within close temporal proximity of each other. One way to alleviate that issue is to use a master Random instance (which is locked by a single thread) to generate some random seeds and initialize new Random instances for every other thread to use.

5

  • 16

    “If you don’t share instances of Random across different threads, you don’t have much to worry about.” – This is false. Because of the way Random was created, if two separate instances of Random are created on two separate threads at nearly the same time, they will have the same seeds (and thus return the same values). See my answer for a workaround.

    Dec 26, 2012 at 2:33

  • 6

    @BlueRaja I was specifically targeting the state corruption issue within a single instance. Of course, as you mention, the orthogonal problem of statistical relation across two distinct Random instances requires further care.

    – mmx

    Dec 26, 2012 at 3:39

  • 29

    I have no idea why this is marked as the answer! Q: “Is Random.Next thread safe?” A: “If you only use it from one thread, then yes it is thread safe”…. Worst answer ever!

    – Mick

    Apr 23, 2015 at 3:55


  • Worst thing you can do is like to outside articles to give an answer and NOT actually include the answer… Especially when it is as simple as this.

    Mar 1, 2018 at 21:46

  • 1

    “they will have the same seeds” This has been fixed in .Net Core.

    – Magnus

    Jul 2, 2020 at 6:19

35

There’s nothing special done in the Next method to achieve thread safety. However, it’s an instance method. If you don’t share instances of Random across different threads, you don’t have to worry about state corruption within an instance. Do not use a single instance of Random across different threads without holding an exclusive lock of some sort.

Jon Skeet has a couple nice posts on this subject:

StaticRandom
Revisiting randomness

As noted by some commentators, there is another potential problem in using different instances of Random that are thread-exclusive, but are seeded identically, and therefore induce the identical sequences of pseudorandom numbers, because they may be created at the same time or within close temporal proximity of each other. One way to alleviate that issue is to use a master Random instance (which is locked by a single thread) to generate some random seeds and initialize new Random instances for every other thread to use.

5

  • 16

    “If you don’t share instances of Random across different threads, you don’t have much to worry about.” – This is false. Because of the way Random was created, if two separate instances of Random are created on two separate threads at nearly the same time, they will have the same seeds (and thus return the same values). See my answer for a workaround.

    Dec 26, 2012 at 2:33

  • 6

    @BlueRaja I was specifically targeting the state corruption issue within a single instance. Of course, as you mention, the orthogonal problem of statistical relation across two distinct Random instances requires further care.

    – mmx

    Dec 26, 2012 at 3:39

  • 29

    I have no idea why this is marked as the answer! Q: “Is Random.Next thread safe?” A: “If you only use it from one thread, then yes it is thread safe”…. Worst answer ever!

    – Mick

    Apr 23, 2015 at 3:55


  • Worst thing you can do is like to outside articles to give an answer and NOT actually include the answer… Especially when it is as simple as this.

    Mar 1, 2018 at 21:46

  • 1

    “they will have the same seeds” This has been fixed in .Net Core.

    – Magnus

    Jul 2, 2020 at 6:19

25

The offical answer from Microsoft is a very strong no. From http://msdn.microsoft.com/en-us/library/system.random.aspx#8:

Random objects are not thread safe. If your app calls Random methods from multiple threads, you must use a synchronization object to ensure that only one thread can access the random number generator at a time. If you don’t ensure that the Random object is accessed in a thread-safe way, calls to methods that return random numbers return 0.

As described in the docs, there is a very nasty side effect that can happen when the same Random object is used by multiple threads: it just stops working.

(i.e. there is a race condition which when triggered, the return value from the ‘random.Next….’ methods will be 0 for all subsequent calls.)

2

  • 2

    There is a nastier side effect of using different instances of random object. it returns the same generated number for multiple threads. from same article: Instead of instantiating individual Random objects, we recommend that you create a single Random instance to generate all the random numbers needed by your app. However, Random objects are not thread safe.

    – AaA

    Oct 4, 2015 at 6:35


  • 1

    This is gold. I’m the lucky one in getting the ZERO result from the Random object

    Oct 23, 2017 at 17:04