Looking for a sponsor to review changes made to two unit tests under jdk/test
david.holmes at oracle.com
Mon Apr 8 23:58:49 UTC 2013
On 9/04/2013 9:41 AM, Mani Sarkar wrote:
> Is there no better way of waiting rather than using the Thread.sleep(n)
> method, I think you will agree that using sleep isn't the most elegant
> way to do things.
No it isn't elegant but there is no explicit way to synchronize with the
GC activity, so generally all you can do is add a sleep to allow
"sufficient" time for the things to happen. For finalization you can do
more because you can synchronize with the finalizer itself.
> I did run the patch without sleep, and it executed perfectly well - just
> curious about the use of Thread.sleep(n) in general, nothing specific to
> this change itself.
> When should/can it be used and when not?
> On Tue, Apr 9, 2013 at 12:28 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
> On 8/04/2013 9:59 PM, Mani Sarkar wrote:
> Thanks Alan, David for your feedback.
> So effectively you are saying the Thread.sleep(10) is fine in
> the test
> and does not need to be re-written using any of the concurrency
> As I wrote back in one of my earliest emails:
> "that aside the latch is not needed. The fork() method starts a
> thread and joins it. So when createNoise() returns we already know
> for certain that the "noise has been created". What the sleep is
> doing is giving the GC a chance to run. "
> The sleep has nothing to do with synchronizing with the "noise"
> thread. And synchronization with the "noise" thread is already
> handled perfectly correctly.
> *Twitter:* @theNeomatrix369
> *Blog:* http://neomatrix369.wordpress.com
> *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs)
> *Meet-a-Project:* https://github.com/MutabilityDetector
> *Devoxx UK 2013 was a grand success:*
> */Don't chase success, rather aim for "Excellence", and success will
> come chasing after you!/*
More information about the core-libs-dev