This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be


http://sourceware.org/bugzilla/show_bug.cgi?id=10320

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> 2012-12-21 20:35:33 UTC ---
I think what you're saying is that srand48, seed48, and lcong48 are modifying
data in non-thread-safe ways, and that erand48, jrand48, and nrand48 are using
some of that data (the part set by lconf48) in non-thread-safe ways. Is this
correct?

The issue seems rather minor to me. srand48 and seed48 have no place in
multi-threaded usage at all; they only set the state for functions which are
not thread-safe anyway. lcong48 does set state that's used by the thread-safe
functions, but even if it did modify this state in a thread-safe way, calling
it at the same time random-number-generating functions are in use would have
unpredictable results.

Considering that it would be prohibitively expensive to make the thread-safe
random number interfaces perform locking to access the state set by lcong48, I
think the right approach to this issue is to open a bug report with the Austin
Group. It seems to me that failure to list srand48, seed48, and lcong48 as
non-thread-safe was just a mistake, not an intentional feature requirement on
implementations.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]