[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
Justin Holewinski
justin.holewinski at gmail.com
Sat Dec 1 08:55:07 PST 2012
If we're keeping the state locally now, perhaps we should store it in a
per-thread variable. I know rand() isn't thread safe to begin with, but it
seems like rand_r() can be since it should keep no external state.
On Sat, Dec 1, 2012 at 11:17 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote:
> Dear all,
>
> In our LLVM-based compiler pipeline a major part of code generation is
> taken into application runtime. One side-effect of this organization is a
> need to be very careful about using code that might diverge application
> state. And we found that simple generation of temporary files over LLVM
> APIs introduces random noise into the program result. There reason is that
> LLVM's GetRandomNumber call uses rand(), that clashes with rand() used in
> application. Taking in account that many client applications developers may
> be not aware of this at all [and just complain to us, that our compiler is
> bad because their program is now wrong], we propose switching to self-
> state maintaining rand() on LLVM side. Attached patch simply replaces the
> calls to srand() and rand() with a call to rand_r(), which uses static
> unsigned x value to keep its state locally.
>
> Best,
> - D.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
--
Thanks,
Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121201/180596ce/attachment.html>
More information about the llvm-dev
mailing list