|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 7
Something else to notice in Listing 1 is that Thread is an abstract class, designed to be subclassed. Its default run() method does nothing, so must be overridden in the subclass definition to accomplish anything useful.
So by now you can see a little bit of what makes programming with threads complex. But the main point of enduring all these difficulties isn't to gain speed.
Multithreaded programs do not, in general, complete faster than single-threaded ones -- in fact they can be significantly slower in pathologic cases. The fundamental added value of multithreaded programs is responsiveness. When multiple processing cores are available to the JVM, or when the program spends significant time waiting on multiple external resources such as network responses, then multithreading can help the program complete faster.
Think of a GUI application: if it still responds to end-user points and clicks while searching "in the background" for a matching fingerprint or re-calculating the calendar for next year's tennis tournament, then it was built with concurrency in mind. A typical concurrent application architecture puts recognition and response to user actions in a thread separate from the computational thread assigned to handle the big back-end load. (See "Swing threading and the event-dispatch thread" for further illustration of these principles.)
In your own programming, then, you're most likely to consider using Threads in one of these circumstances:
Thread naturally expresses the application's required programming model. Suppose, for instance, that you were modeling the behavior
of rush-hour automobile drivers or bees in a hive. To implement each driver or bee as a Thread-related object might be convenient from a programming standpoint, apart from any considerations of speed or responsiveness.
Experienced programmer Ned Batchelder recently quipped
Some people, when confronted with a problem, think, "I know, I'll use threads," and then two they hav erpoblesms.
That's funny because it so well models the problem with concurrency. As I already mentioned, multithreaded programs are likely to give different results in terms of the exact sequence or timing of thread execution. That's troubling to programmers, who are trained to think in terms of reproducible results, strict determinacy, and invariant sequence.
It gets worse. Different threads might not only produce results in different orders, but they can contend at more essential levels for results. It's easy for a newcomer to multithreading to close() a file handle in one Thread before a different Thread has finished everything it needs to write.
Threads programming
Thread synchronization
Locks and monitors
Testing and debugging threads
Threads & alternatives