Dmitry Mikushin
2012-Dec-01 17:12 UTC
[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
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>
Dmitry Mikushin
2012-Dec-01 19:25 UTC
[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
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>
Justin Holewinski
2012-Dec-02 00:02 UTC
[LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
I don't know if __thread is well-supported enough on compilers to use in LLVM core code. LLVM has its own support class: ThreadLocal http://llvm.org/doxygen/classllvm_1_1sys_1_1ThreadLocal.html And if randr_r() is obsolete, I'm not sure we should be using it. What platforms have you tested this on? Is it available on Windows, Mac, BSDs? If not touching global state is important enough, perhaps we should add a (simple) random number generator to the Support library. I don't think LLVM would require anything fancy. On Sat, Dec 1, 2012 at 2:25 PM, Dmitry Mikushin <dmitry at kernelgen.org>wrote:> 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 >>> >>> >> >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121201/9567092f/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
- [LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
- [LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
- [LLVMdev] Use rand_r() instead of non-reentrant thread-unsafe rand() in GetRandomNumber()
- [LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build