In Java, the real work in dealing with threads is usually in understanding them. The syntax for creating and "launching" them is fairly simple.Indeed, even grasping the basic concept of the thread is fairly simple compared to understanding the practical subtleties of how it's applied usefully in programming. In other words, it's easier to make a thread than to understand why or where to use one. But that's getting ahead of ourselves.
We focus in this week's column on the underlying theory and basic application of threads. If you're not new to this concept in programming, feel free to tune us out. If we haven't lost you yet, we need to clarify something: Threads per se are not anything new to programming. In fact, the single execution "thread" is about as old as programming itself. A relatively more recent invention is multithreaded programming, and even this itself is far older than Java.
The thread metaphor is relatively simple: A single thread represents the average program, with linear, orderly execution from start to finish. In the case of a multithreaded Java program, there's more than one single thread. The various threadable objects within it may all execute simultaneously. Your program multitasks.
You may wonder, if your operating system multitasks between different programs, why would it make any sense to be able to multitask within the programs themselves as well? It's done foremost because, once the programmer gets the hang of it, it can be a powerful programming advantage, making code more straightforward and elegant. It may make a great deal of sense to have several tightly integrated but separate "lightweight processes" operating within one program framework--sharing some of the same resources and data.
In weeks leading up to this, we've alluded to threads in the context of handling video and audio. To illustrate by way of example, one of the more pragmatic uses of the thread (especially common in a number of Java applets on the Web) is to manage the loading and presentation of audio and video. This is exactly what we touched on at the end of last week.
Perhaps the simplest way to make your call to getAudioClip() (a method for "loading" a piece of audio data) happen while leaving the rest of your main thread ticking along is to make a new class that is inherited from the java.lang.Thread class.
In much the same way that we talked about redefining standard methods in a previous column, we redefine here the
run()method.run()should contain whatever code we want to run within the new thread. Calling your new object'sstart()method kicks it off. More generally, it looks like this:
... class testThread extends java.lang.Thread { ... run () { /* This thread's instructions go here */ } } ... /* Back in the main() program: */ new testThread.start();
In fact, the audio example in the Sun Java Tutorial makes use of this technique, albeit a fairly sophisticated version of it.Deeper below the surface are issues regarding how CPU time is divided between the various threads (Priority), how threads can share information, synchronize their activities, and how they can be easily managed by the user.
Most importantly, we've still got quite a bit to discuss about why and where threads are employed in effective Java applets. Stay tuned for part 2 of our exploration of threads.