[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
Dmitry Mikushin
dmitry at kernelgen.org
Sat Dec 1 09:12:26 PST 2012
Agreed, done.
One thing I'm not sure about is this statement in docs:
POSIX.1-2008 marks *rand_r*() as obsolete.
- And... what is the replacement?
2012/12/1 Justin Holewinski <justin.holewinski at gmail.com>
> 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/823c9b61/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.rand.patch
Type: application/octet-stream
Size: 410 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121201/823c9b61/attachment.obj>
More information about the llvm-dev
mailing list