RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread (original) (raw)
Peter Levart peter.levart at gmail.com
Tue Jan 15 14:50:25 UTC 2013
- Previous message: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
- Next message: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 01/15/2013 03:38 PM, Aleksey Shipilev wrote:
On 01/15/2013 06:33 PM, Peter Levart wrote:
One more thing, not related to serialization:
If a TLR reference is somehow passed from the thread that obtained it via TLR.current() to some other thread that did never call TLR.current() and this other thread calls methods on such instance (nextInt(), ...), it will start the random sequence from the zero seed, bypassing localInit() call... Is this ok? I think this counts as "accidental" sharing, and Javadoc recommends to always do TLR.current().* to take the appropriate TLR; hence I think this is the adopted failure scenario. The upside for not fixing this is skipping the initialized checks from each of next*() methods, which are needed in corner cases only, thus saving the hot-path performance.
If javadoc recommends to always do TLR.current() then this method is also hot-path. So why not move the initialization check from current() to next(int bits)? Well, the following usage pattern can save some checks in the original case:
TLR r = TLR.current();
r.next*(); .... r.next*(); ....
Regards, Peter
-Aleksey.
- Previous message: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
- Next message: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]