3 ms·
The author's multithreaded random_r version has the benefit of performance, but has the problem of, well, brokenness. Without locking the internal state of ran
by fche 12y ago
The author's multithreaded random_r version has the benefit of performance, but has the problem of, well, brokenness. Without locking the internal state of random_r(), it will be corrupted, and the results won't be meaningful.
- mjb 12y agoCan you explain more? My understanding (which seems to be backed up by the implementation) is that I can call initstate_r in each thread to initialize thread-local state, then call random_r without synchronization from each thread as long as I used that thread's thread-local state. random_r's internal state is all, from what I can see of the implementation, entirely passed in by the caller. Implementation here: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/random_r.c;h=87cfdc285c0f6e4a4911eac0f6dd5efa2c3fb8b6;hb=9752c3cdbce2b3b8338abf09c8b9dd9e78908b8a https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/rand...
- ScottBurson 12y agoYou are correct, and 'fche is mistaken. Each 'random_data' object is accessed only from a single thread.
- barrkel 12y agorandom_r doesn't have internal state.