Basics of Csharp Computer Programming Logic and Design: With Hyper-Threading Technology arriving on the desktop, programmers are having to think of their applications as multithreaded compositions. The single-threaded model will disappear save for embedded-processing contexts.

---

by Andrew Binstock, principal analyst, Pacific Data Works LLC. Intel Corp.

This column focuses on how changes Intel makes in its processors affect software development. As almost all programmers know, the relationship between programming and the underlying processor has historically been fairly close. In the early days of assembly language, of course, the two were tightly linked: every instruction depended on the programmer's knowledge of the processor underneath. The introduction of high-level languages (HLLs) such as COBOL, Fortran, and C removed some need for processor-specific knowledge, but by no means all of it. As little as ten years ago, developers had to handle a variety of memory models on PCs and servers whose distinguishing characteristics were strictly the address size and integer width of the silicon below. The big-endian vs. little-endian problem—another function of processor design—continues to afflict data that must be moved across processor platforms.

In recent years, operating-system vendors attempted to reduce the dependency of code on processor characteristics. Notably, these efforts include Java* and .NET, which have considerably reduced differences in data formats and the size of data elements. On the surface, the success of these technologies would suggest that developers no longer need know about the processor details. Such is not the case, however. Consider, for example, Hyper-Threading Technology, which allows two different execution threads to run on the same physical processor. Intel has already announced that Hyper-Threading Technology to migrate from its current home on Intel Xeon processors to desktop systems in the near future. This event represents, in my view, a signal moment in the history of computer programming. From then on, as Hyper-Threading Technology works its way into the basic deployment platform, programming for multithreaded applications will need to become the default way programmers think. The long-established single-threaded model used by most developers of client-side applications will become obsolete.

This is a big change which fundamentally affects Java, .NET, C++, and assembly-language programmers equally. For this reason, I've decided to focus first few installments of this column on the transition to multithreaded applications and Hyper-Threading Technology in particular.

But even for changes in silicon less dramatic than those accompanying Hyper-Threading Technology, developers still need to understand how to take advantage of the new instructions and capabilities of new generations of Intel chips, such as the Intel Xeon processor or the newly released Itanium 2 processor. Developers at ISVs in particular, as well as those working in industries such as financial services or the defense sector, need actionable data on processor specifics. Likewise, developers working on multimedia applications will be richly rewarded by knowing the ins and outs of Intel's extensive innovations in this area.

It is likely the trend towards software layers that further obscure the inner operations of the processor will continue to advance. And likewise, developers who can make best use of those software layers to exploit the processor below will produce conspicuously better software. So let's get started.

Moving to multithreading
As I mentioned, Hyper-Threading Technology, which exists in Intel's Xeon processors today is coming to the desktop. Most analysts expect the transition to begin occurring in 2003. Whenever it occurs, it will require programmers to begin thinking of their applications in a new way: as multithreaded compositions. The old single-threaded model that has been around since time immemorial (OK, sixty years) will disappear save for its role in embedded-processing contexts.

This transition from the single-threaded model to multiple threads is by no means trivial. It requires developers to think about problems rather differently—much like object orientation (OO) transformed program design in the early 1990s. And, as is ever true, technologies that require us to change the way we think about solutions require a lot of getting used to. This is much more of a paradigm shift than technologies, such as new programming languages, that require us to change only how we express our solution to a problem, but not the structure of the solution itself.

Why care about multithreading at the program level?
Multithreading occurs at both the application and operating-system levels. And if the operating system can map programs and systems services to the processors by itself, why should developers spend any time or effort worrying about implementing multithreading in their applications?