To consolidate a few comments...
Making multiple calls to a getRand()
function which reads from /dev/urandom is slow and should be avoided, as it uses system calls which add a lot of overhead. It is better to read much larger chunks from /dev/urandom and buffer them, or to use /dev/urandom to seed a software PRNG.
In the latter case, OpenSSL's RAND_bytes()
can be used which returns "cryptographically strong random" values. This can be configured to use Intel's DRNG via the RDRAND instruction (see http://wiki.openssl.org/index.php/Random_Numbers#Hardware) which is discussed here. This actually uses a hardware implementation of AES in counter mode via the AES-NI instruction set (which can also be accessed directly through OpenSSL's EVP API). According to Intel the RDRAND-enabled version of OpenSSL outperformed the non-RDRAND version by an order of magnitude.
Two approaches (discussed in this post) for generating random numbers for multiple threads are either to seed a seperate PRNG for each thread from /dev/urandom, or to seed one PRNG from /dev/urandom and then seed each thread's PRNG from that one.
It should be noted, though, that OpenSSL is not thread safe. This post gives a good example of using OpenSSL with OpenMP.