[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()

Dmitry Mikushin dmitry at kernelgen.org
Sat Dec 1 11:25:55 PST 2012


Correcting my patch, reg. __thread stuff I'm not very familiar with.

- D.

2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org>

> 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/9170e083/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.rand.patch
Type: application/octet-stream
Size: 416 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121201/9170e083/attachment.obj>


More information about the llvm-dev mailing list