RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again (original) (raw)
Daniel Fuchs daniel.fuchs at oracle.com
Tue Apr 15 06:54:14 UTC 2014
- Previous message: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Next message: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi guys,
Should 'actual' and 'reference' be declared as volatile?
I see that they are accessed from main() after joining the threads. Or does joining the threads guarantees that 'main' will see the right values?
best regards,
-- daniel
On 4/15/14 8:48 AM, David Holmes wrote:
On 15/04/2014 4:10 PM, Ivan Gerasimov wrote:
On 15.04.2014 6:23, Mandy Chung wrote: On 4/14/2014 11:26 AM, Ivan Gerasimov wrote: Actually, zero tolerance should be sufficient now even for Windows platform. Measuring the time with nanoTime() should make the inner and outer time intervals consistent.
I've added the tolerance just to play safer. I can remove it. That'd be even better! Alright, I removed the tolerance back. So now the only change is how the time interval is measured: http://cr.openjdk.java.net/~igerasim/8038982/1/webrev/ This is the right change to make. I'm a little surprised we are seeing these timing problems though. That said the resolution of timed blocking calls and the resolution of currentTimeMillis() can be quite different on any platform, not just windows. In general nanoTime should always be used to measure elapsed time. Thanks, David Sincerely yours, Ivan thanks Mandy
- Previous message: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Next message: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]