rand() and thread safety

[eyal.susser]

I hear rand() is not thread safe. I was using it, foolish man that I
am. But what is meant exactly by unsafe? What can happen? Bizzare
results from rand()? Something worse?

Thanks,
Eyal.

 

[eyal.susser]

Oh, just to make things clear, I wasn't reading the return value from
rand() in two threads or something. I was just calling it in one
thread, locally, and using it just there. Could that still pose a
problem?!

Thanks

 

[Pete Becker]

I hear rand() is not thread safe. I was using it, foolish man that I
am. But what is meant exactly by unsafe? What can happen? Bizzare
results from rand()? Something worse?

Ask whoever said it.

Generally speaking, neither the C nor the C++ standard imposes any
requirements on code used in multi-threaded applications, so it's
vacuously true that nothing in either language is thread safe. More
usefully, though, compiler writers and library writers generally know
that people sometimes write multi-threaded applications (even when they
shouldn't, but that's a separate discussion), and take reasonable care
to ensure that their code works "correctly" in multiple threads. Ask
your vendor what "correctly" means.

 

[eyal.susser]

Wait, are you saying that on some platforms (gnu mips compiler, for
example), behaviour could be truly and really undefined? As in a call
to rand() corrupting memory due to some unfortunate thread timing?
Even if the rand() is used locally in a thread (return value not shared
among threads)?! I will be shocked out of my shoes if you say yes! ;-)

Thanks

 

[Alexander Terekhov]

Ask whoever said it.

Generally speaking, neither the C nor the C++ standard imposes any
requirements on code used in multi-threaded applications, so it's
vacuously true that nothing in either language is thread safe. More
usefully, though, compiler writers and library writers generally know
that people sometimes write multi-threaded applications (even when they
shouldn't, but that's a separate discussion), and take reasonable care
to ensure that their code works "correctly" in multiple threads. Ask
your vendor what "correctly" means.

POSIX defines "Reentrant Function": "A function whose effect, when
called by two or more threads, is guaranteed to be as if the threads
each executed the function one after another in an undefined order,
even if the actual execution is interleaved" (just like everything,
it holds as long as application doesn't trigger undefined behavior
[for example by using pointer arguments which lead to violation of
XBD 4.10]). With respect to rand(), it says "The rand() function need
not be reentrant. A function that is not required to be reentrant is
not required to be thread-safe.". Under TSF option, POSIX provides
"thread-safe" rand_r() function.

regards,
alexander.

 

[Pete Becker]

Wait, are you saying that on some platforms (gnu mips compiler, for
example), behaviour could be truly and really undefined?

Ask the GNU folks.

 

[eyal.susser]

OK, thanks everyone!

 

[Ioannis Vranos]

Oh, just to make things clear, I wasn't reading the return value from
rand() in two threads or something. I was just calling it in one
thread, locally, and using it just there. Could that still pose a
problem?!

No problem at all.

Also a compiler that supports multithreading, usually provides a thread-safe
implementation of the standard library. Otherwise it will state in its documentation if
something is not thread safe.