The proliferation of parallel processing hardware is creating a fast-growing need for multithreading skills. A developer who cant write safe and efficient concurrent code may waste up to half the power of the dual-core CPUs already found in laptop PCs and up to three-quarters of the power of the quad-core CPUs that Intel announced it plans to ship in November.
Even Intel—formerly a loud promoter of clock rate as the metric of microprocessor leadership—has clearly drunk the Kool-Aid of getting more work done per clock cycle.
Hyperthreading within a single core, single CPUs with multiple cores and multiple CPUs in even the most compact servers are the pathways that are being most actively explored by both Intel and Advanced Micro Devices in the x86 world and by Sun Microsystems and others for other CPU architectures.
Intels investments in college curricula and resources for multithread development training and its August release of new tools for multithread code optimization send additional signals that no developer should ignore.
Guru Jakob Nielsen offers advice on designing applications for usability.
Click here
to watch the video.
The Java programming language, like Ada before it, lets developers express concurrency in the same language that theyre already using for application logic. This avoids the need to devise a new meta-language, bloating and complicating their code, for that purpose.
Developers using languages such as C++ are not being left behind: Concurrency tool kits and frameworks, including Intels Threading Building Blocks for C++ (which debuted at the end of August), also offer powerful abstractions. A developer using Intels library can summon up, for example, an instance of the class Parallel_Task and fill that fully managed container with the task-specific details of the computations to be made.
Even so, developers should not underestimate the challenges that they still face. They may wrongly expect that theyll be able to count the threads that theyre using on the fingers of one hand: one for user input, one for network interaction, one for graphical operations and so on. Thats a naively optimistic view, according to Brian Goetz, principal author (with five co-authors) of “Java Concurrency in Practice,” an Addison-Wesley title published in May.
The authors were members of the Java Community Process Expert Group that defined new high-level components and low-level mechanisms for improved concurrent development in Java 5.0 (more here).
“The need for thread safety is contagious,” these authors warn, since “frameworks may create threads on your behalf, and code called from these threads must be thread-safe. … Frameworks by their nature make callbacks to application components that in turn access application state.” The need for thread safety, they observe, further “extends to all code paths that access the program state accessed by those components.”
There are two key ideas in just this brief passage that developers may find useful. The first is the suggestion by the authors that developers should not let themselves become overwhelmed by the mechanisms of threading but should rather stay focused on the question of application state.
If developers can accurately identify the places where an application is maintaining state, they may then be able to form a clear mental picture of the pathways in their code that have the power to alter that state. Developers can then take measures to ensure that no such alterations can create invalid state. For example, a developer can write code (or use a thread-safe counter) to make sure that an event-counting variable has been incremented by one thread before any other thread is allowed to look at the variables previous value.
Developers must also appreciate that multithread environments may expose careless habits that are wrong, but tolerable, in simpler single-thread environments.
“Code confidence is about as close as many of us get to correctness,” the authors of “Java Concurrency in Practice” warn. A clear specification has always been a good starting point for any nontrivial code, but in multithread environments it becomes even more essential.
What the brain lacks language to describe, the mind cant even imagine—or so some linguists claim. As coders face the challenge of writing programs for multicore and multi-CPU machines, they depend on designers of programming languages and builders of application frameworks to create an effective vocabulary of concurrency.
Peter Coffee can be reached at peter_coffee@ziffdavis.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.