Random numbers generated in separate functions aren't so random

Question

I have two separate functions that each generate a random number from the same range (1-5). Unfortunately, ~90% of the time they generate the same number. I know that within a single function you solve that problem by re-using the same Random object because it's happening so quickly that the system clock has yet to really change and seed a different "random" value, but when it's spread across more than one function what is the best approach to resolving this? The whole process takes about a full second to complete and these functions are not called back-to-back, so surely (I would think) the clock has ticked in between them, but is that not true?

I have some ideas for how to generate the numbers using an algorithm instead of just Random but they would be more taxing and I feel there's a simpler solution.

Edit: Can the people who downvoted please explain? I'd be happy to improve the question based on your suggestions.

Answer 1

Ways out of this hole:

• Pass a single Random object around as needed.

• Make the Random object a static public field of a class visible to everything that needs it. Note that Random is not thread safe. If you need it to be thread safe then either put locks around it, or make it thread local and allocate one for each thread.

• Use crypto strength randomness. It doesn't have this problem.

• Write your own pseudo random number generator that has better behaviour than the built-in one.

• Use another source of randomness entirely, like downloading a blob from random.org or some such thing.

A now-deleted answer suggests using NewGuid as a source of randomness. Do not do this. Guids are guaranteed to be unique; they are not guaranteed to be random. In particular, it is perfectly legal for a guid generator to generate sequential unique guids. That NewGuid does not actually do so is not part of its contract. Use guids for what it says on the box: the box says "globally unique identifier", not "randomly generated identifier".

A commenter suggests using a hash code as a source of randomness. Do not do this. Hash codes are guaranteed to be randomly distributed only so far as they need to be to give a good distribution in a hash table. In particular, we have no guarantee whatsoever that hash functions were designed to ensure that their low order bits are well distributed.

Use only sources of randomness or pseudo-randomness that were designed by experts to produce randomness. Generating randomness is a difficult engineering problem. Just because you think you can't predict a particular outcome does not make that outcome a suitable source of entropy for a random number generator.

Answer 2

A quick solution is to share the random seed between your consumers.

One way to do that is creating a provider:

public class RandomIntegerProvider 
{
     private static Random _globalRandomGenerator = new Random();

     public int Next()
     {
       //...
     }
}

Edit:

A very interesting post about that:

http://blogs.msdn.com/b/pfxteam/archive/2009/02/19/9434171.aspx

You can play with different strategies and even ensure thread safety.

Answer 3

The OOP-friendly way would be to pass it through a parameter to a function, or through a constructor parameter to a class, where it would be stored as a field / property.

This is called dependency injection - it's what you should be doing, if you want your applications to be testable and scalable!

An example:

void Caller()
{
    Random random = new Random();
    Foo(random);
    Bar(random);
}

void Foo(Random random)
{
    int randomNumber = random.Next();
}

void Bar(Random random)
{
    int randomNumber = random.Next();
}