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?


 
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

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 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...

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

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

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

The Race Is On to Debug Dual-Core Deadlocks


Exploring best practices for building parallel applications

By Jennifer deJong
February 1, 2006 — 
You write a program. You test it. You ship it. Then, mysteriously, it doesn’t run.

What’s the culprit? Most likely, a deadlock or a race condition, said James Reinders, a senior engineer at Intel. Both errors can grind a multithreaded application to a halt, and are notoriously difficult to detect. “They simply don’t exist in sequential programs,” he said.

Deadlocks and race conditions aren’t new; they’ve afflicted multiprocessor systems, particularly large servers, for many years. But dual-core processors for the desktop, delivered by AMD and Intel last year, are bringing them to the fore. That’s generating renewed interest in an old problem: the difficulty of designing and coding applications that execute multiple processes concurrently.

Dual-core processors don’t fundamentally change the way developers write applications, said Margaret Lewis, director of commercial ISV marketing at Sunnyvale, Calif.-based chipmaker AMD. But they further enable multithreading—also known as concurrent development or parallel programming—in which an application sends “multiple execution strings to the processor,” she said.

Threads within multithreaded applications, which also can run on single processors, often compete for shared resources (such as memory and disk space) as well as variables and functions. A deadlock can occur, for example, when a multithreaded application locks a resource and fails to unlock it once the thread has completed its task, said Andy Yang, product manager at

San Francisco-based Coverity, which sells a source code analyzer, among other tools. “The system freezes up.”

Race conditions happen when threads compete for the same resources and the application fails to specify the order in which the threads can access those resources. “You solve the problem with synchronization,” said Reinders. “If the flag is up, don’t take [the resource]. If the flag is down, it’s available.”

Detecting either error is difficult because collisions don’t always occur, so pinpointing the problem is a matter of timing, said Ken Cowan, a product line manager for Detroit-based Compuware, which sells coding, testing and other tools. When QA tests the app by hand, the error doesn’t appear, but it may show up in load testing, he said. “With 50 users, the application fails. And it’s not clear why.”

Avoiding such errors takes skill. “Don’t write multithreaded code if you don’t know what you are doing,” said Roger Thornton, CTO of Palo Alto, Calif.-based Fortify, which sells application security tools. Because such applications execute tasks in parallel, instead of sequentially, the developer has to understand the principles of how a program shares resources, he said. Without that knowledge, errors are a likely outcome.

Thread-Safe
Java and C# are “thread-safe,” while older languages such as C and C++ must rely on the third-party libraries to provide that capability. Thread safety is important because it reduces the risk of collisions, said Thornton. “The runtime knows to lock your functions, but you still need to understand [the concept of] threading,” he said. Thread-safe tools don’t shield developers from the complexity of writing multithreaded apps, added Compuware’s Cowan. “They let programmers who don’t understand concurrent programming [practice] it,” he said. And that can get them in trouble.

“It’s kind of like giving a loaded gun to kids,” echoed Coverity’s Yang. “Make sure you have the proper experience level.”

To avoid trouble, begin by addressing concurrency issues in the design phase. “You have to think about shared data between multiple threads” and make sure you use synchronization locks consistently, said Cowan, referring to the process of locking and unlocking shared resources in concurrent applications. “It is tricky to implement.”

Designing for concurrency is about getting a clear focus on how to decompose a problem, added Intel’s Reinders. “You are asking: ‘How do I break this program up?’”

The key is to approach the application’s design the same way a group of people approaches a task, such as collecting old Christmas trees and chopping them up. The trees are collected in parallel; they are chopped up in parallel, he said. “It’s natural to think that way.”

For multi’s sake
The point of multithreading is to boost performance. Use it to that end, not just for the sake of it, said Fortify’s Thornton. Developing apps that can execute tasks simultaneously offers developers a freedom that doesn’t exist with sequential programs.

“But you have the responsibility to weigh the trade-offs,” he said. “Sometimes you may go back to the design and find you didn’t need threading.”

And even when an application calls for concurrency, developers must figure out how to divvy up the work so multiple processors don’t have to synchronize too often.

“Two or three operations can run in parallel and you get performance benefits,” said AMD’s Lewis. “But the next level of performance gains is harder.” The best candidates for parallelization are tasks that are not heavily interdependent, such as pulling data from a Web server while simultaneously updating the user interface. “Simple things result in the most immediate returns.”

As dual-core chips gain currency, developers should analyze existing applications—both multithreaded and sequential—to spot opportunities for incremental improvement. (Tools such as Thread Checker from Intel and CodeAnalyst from AMD can help pinpoint them.) “Look for compute-intensive [operations] that process a lot of data, such as resizing or removing red eye from digital photos,” said Intel’s Reinders. Doing that is a matter of rewriting a subroutine that lets two processors share the job, he said. “In the long run, every software program out there will take advantage of multiple processors.”


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading