LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
A knockout blow for Borland?
MicroFocus has upped its offer for Borland Software to $1.50, hoping to chase off a mystery suitor also pursuing the ALM vendor.
07/06/2009 12:26 PM EST

Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

Telerik looks to boost 3D for Silverlight
In a new release of its RadControls component suite, the company introduced a 3D charting ...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

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


Share this link: http://www.sdtimes.com/link/31279
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading