Andrew Binstock: Threadbare! - Software Development Times On The Web

Andrew Binstock: Threadbare!
By Andrew Binstock

November 1, 2007 — The vendors most concerned with promoting threading on the desktop—that is, chip vendors whose future is closely tied to capitalizing on multiple cores—are slowly but inevitably coming to a disappointing conclusion: Desktop developers are not interested in threading. And no amount of flag waving or promotion is going to persuade them to adopt threads.

Intel has certainly been trying. It recently made its Threading Building Blocks available for free and got O’Reilly and Associates to release an entire volume documenting the software’s use. Intel also offers several very good threading tools. And, along with several vendors, the company has pushed the development and distribution of OpenMP, which is probably the simplest way today to implement threading. The results of all this effort have been undetectable, so far. Gamers, multimedia apps and software from ISVs are still the primary, perhaps exclusive, users of threads on the desktop. No one else cares.

Why the resistance? Several reasons. First, a strong case for threading has not been made. Everyone understands how it runs software faster. But if users aren’t pushing for greater performance than they’re currently getting from desktop apps, the effort to add threading lacks a compelling driver. Second, threading is hard. It requires a different mindset from the straight-ahead programming most developers know, and it demands new skills, such as special design and debugging prowess. Third, the frameworks and languages lack robust support. Threads are supported in Java and .NET, but primarily as primitive resources. High-level support is notably weak.

Dynamic languages are even further behind. To wit, Python, allows only one thread to run at a time (except for I/O); this means you can have threads but not running in parallel. Ruby can run threads only within the one VM, which is arguably better but nowhere near good enough. And OpenMP, which might be a solution for some, is limited to C++ or Fortran.

Fourth, development tools lag in thread support. The major IDEs provide basic support, but for anything more, you have to go to third-party products. Alas, there are few of these; the most notable is a trio of products from Intel. While there are one-off offerings elsewhere, there is little tool help overall for the programmer who wants to go parallel.

So, without a compelling driver, good framework or language support, or good tools, why would any developer dive into threading? Put another way, lots has to change before threading on the desktop is adopted widely.

One solution is for Java and .NET frameworks to add solid threading support that makes it easier for developers. For example, an equivalent of OpenMP for Java and .NET could be developed. This step would definitely help, but it’s not likely to appear anytime soon. Java has been adding concurrency features since Java 5, and the upcoming Java 7 will add more, likely including a thread-aware queue that makes certain types of data transfers between threads far easier. However, these advances are comparatively low level and will help only developers who are already committed to threading.

At a lower level, x86 chip vendors have been doing their best to provide threading support in silicon by expanding the instruction set to execute primitive operations efficiently.

All recent x86 chips, for example, contain a family of instructions that compare two values and swap them if they’re different. This seemingly unimportant task actually is a way of updating the value of a variable: See if the new value is different from the current value, and swap it into the variable if it is. The single-instruction aspect is crucial because it enables the update to be atomic. That is, the thread cannot be preempted or otherwise interrupted during the update. And it performs the operation without locking the variable. This instruction, then, is a fast way to update shared variables.

Recent processors also sport the mwait/monitor pair of instructions. These work in tandem to suspend a thread until a variable (or an area of memory) changes value. When an update occurs, the processor wakes up the thread that issued the mwait instruction. By performing this operation in silicon, chips relieve developers from writing heavy constructs to wait for a specific variable to change. These instructions are primarily intended for use by operating systems, rather than applications. However, they portend a likely increase in threading features in future processor generations.

These steps will not be enough. For threads to catch on, customers need better language and framework support, and more tools will all have to appear. Until then, desktop threading will remain a rare practice.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE COLUMNS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/1/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

SHARE 2008
8/10/2008 to 8/15/2008
San Jose
SHARE

ACM SIGGRAPH
8/11/2008 to 8/15/2008
Los Angeles
ACM SIGGRAPH

Intel Developer Forum
8/19/2008 to 8/21/2008
San Francisco
Intel

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA