By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,191 Members | 757 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,191 IT Pros & Developers. It's quick & easy.

rand() and thread safety

P: n/a
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.

Jul 23 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
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

Jul 23 '05 #2

P: n/a
ey*********@gmail.com wrote:
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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #3

P: n/a
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

Jul 23 '05 #4

P: n/a

Pete Becker wrote:

ey*********@gmail.com wrote:
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.


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.
Jul 23 '05 #5

P: n/a
ey*********@gmail.com wrote:
Wait, are you saying that on some platforms (gnu mips compiler, for
example), behaviour could be truly and really undefined?


Ask the GNU folks.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #6

P: n/a
OK, thanks everyone! :-)

Jul 23 '05 #7

P: n/a
ey*********@gmail.com wrote:
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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.