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.
David
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? Cheers, mani On Tue, Apr 9, 2013 at 12:28 AM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@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 library methods. 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. David ----- -- *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:* http://www.devoxx.com/display/UK13/Home */Don't chase success, rather aim for "Excellence", and success will come chasing after you!/*
