8.4 Coordinating Threads Using Long Sleep Times

 < Day Day Up > 



8.4 Coordinating Threads Using Long Sleep Times

The first way to try to fix the problem of the ball jumping across the screen is to fix the sleep time in the thread at some value that is always larger than the time it could possibly take to move the ball across the screen. For example, if the sleep time is greater than 100 seconds, the ball should always finish moving across the screen before the sleep is finished. This solution is not something I would have ever thought of; it comes from looking at a number of students' programs as they try to solve this problem. Even when given a correct methodology for solving the problem, many students will still try to make a solution by timing the threads. There appears to be something comforting about controlling the threads through some external mechanism, such as long sleeps, or by starting, stopping, and suspending the threads, even if doing so results in incomprehensible and incorrect programs. Solutions developed using these types of strategies are almost always a bad idea and seldom result in a correct program. In fact, the suspend, resume, stop, and destroy methods were so frequently used incorrectly that they have been deprecated in the Java API. [2]

Why does using a large value of sleep time result in incorrect programs? The first problem with using a large value of sleep time is that it is not really possible to define a large enough sleep time. This is not as obvious as it may seem. I once worked on a program that was getting strings back from a server and processing them. It had been modified by a programmer who did not understand cooperative synchronization but needed to find a string from the server. Rather than try to coordinate threads, he set a sleep time that always worked for him. Over time, however, the server became more bogged down until this sleep time was occasionally exceeded, causing an error in the program. Because the error was very intermittent it was extremely difficult to reproduce and find, requiring weeks of debug statements, trial and error, and sleepless nights. Once I discovered the problem, however, a correct solution that did not rely on waiting a long enough time was easily implemented. The moral here is that one cannot test a concurrent program to prove that it is correct; one can only show that it works under the given assumptions. Unless a sleep time is set to an outrageously large value, the programmer can never be certain that external circumstances will not at some point make the value too small. And, when the program starts experiencing problems resulting from bugs in the wait times (and bugs will eventually occur), they most likely will be very difficult to find.

The second problem with creating a large value for the sleep time is that it might not be appropriate for the problem. For example, in the animation the value of the sleep time might be tied to some external constraint where the movement of the ball being used is part of the overall calculation of an average time in a simulation. Increasing the sleep time simply invalidates the entire simulation. An even worst case would be if a very large sleep time were used by a thread in a server. This could cause the server to suspend processing every request for an inappropriately long time, as happened in the GUI thread in Chapter 7, causing the server to have very poor response times and throughput. It is nearly always a bad idea to randomly sleep in a program, particularly to use sleep to coordinate threads.

The final reason why arbitrary sleep times is a bad idea is that it does not even solve the problem we are trying to address. In the animation in Exhibit 1 (Program8.1), we have no guarantee that movement of the object will finish before the sleep is complete. Unless the sleep time is infinite, there is always a non-zero possibility that the sleep will complete before the move; therefore, using sleep times cannot ever be guaranteed to be correct and will likely result in bugs at some point. Using statistics to demonstrate that the likelihood of a bug is so low as to be acceptable is sometimes used, even in hard real-time programming, and can occasionally be used when a problem cannot be solved in another way. But, doing so requires the use of statistical analysis to predict the possibility that the timing of the program avoids a problem to a sufficiently low probability, which is not an easy task. Also, because most types of problems have correct solutions that are easy to implement, all of these tricks using sleep times are really unnecessary. So, as a rule sleep time should not be used to coordinate threads.

[2]For more information, read the Java API for class Thread.



 < Day Day Up > 



Creating Components. Object Oriented, Concurrent, and Distributed Computing in Java
The .NET Developers Guide to Directory Services Programming
ISBN: 849314992
EAN: 2147483647
Year: 2003
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net