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


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
ASP.NET MVC 2 Ships
ASP.NET MVC 2 has shipped.
03/12/2010 10:26 AM EST

Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

About CSS processing
Two sites that lead to a startling CSS conclusion.
03/10/2010 02:29 AM EST

 

Events calendar tab
SHARE
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

Cloud Connect
3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

Microsoft MIX10
3/15/2010 to 3/17/2010
Las Vegas
Microsoft

SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget


 
print Printable version 
Most Read Latest News Blog Resources
Even with its success, .NET causes some consternation
Despite its popularity, the developer community believes that .NET isn't being fully serve...

Appcelerator dev environment targets Android, iPhone
This unified development environment compiles JavaScript into Objective-C or Java, and wil...

Eclipse creates new sub-projects for Mylyn
The sub-projects are designed to help organizations adopt agile ALM, and they will also br...

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

Presenting the Threading Maturity Model


By Alan Zeichick
February 15, 2007 — 
Threads are breaking out of the server into the desktop and notebook computer—and even in servers, the advent of dual-core and quad-core processors is drastically changing the landscape for applications. To put it bluntly, applications need to be designed, coded and tested to run optimally in a multithreaded environment—not just to get the best possible performance or throughput, but also to ensure that applications will run correctly when there are four, eight or even 16 cores in the machine.

The problem is that most developers, and development teams, don’t think about threading on the desktop. Even when it comes to servers, which have long supported multiprocessing, a lot of the thinking is that “the operating system will handle it,” or “my libraries will handle it,” or “my runtime will handle it.” Well, no. Most of the time, if the architect, coder or tester doesn’t put in the time, you won’t see the results.

When I talk to companies like AMD or Intel, that’s the frustration I hear all the time: Threading is still in the earliest stages of adoption among developers. That’s true on the desktop and the server. That’s true of ISVs and enterprise developers. That’s true for those building libraries and runtimes, and for those building complete applications.

But how to measure how far a company, a development team or a developer is in regard to threading? During lunch at Macworld with James Reinders, director of marketing and business for Intel’s Software Developer Products Group (that is, the compiler folks), I proposed a Threading Maturity Model (ThMM), analogous to such things as the Capability Maturity Model and the SOA Maturity Model.

Note that companies would likely be at different stages in the Threading Maturity Model for server applications versus for desktop applications.

THE THREADING MATURITY MODEL (THMM)
5. Adoption. All developers trained to use threading. Threading is addressed at the design, requirements and architectural states of development, in addition to coding and testing. Broad incorporation of threading tools into the toolchain. Newly adopted code, such as libraries and components, must demonstrate support for threading. Funded efforts to eliminate all nonthreaded libraries and runtimes. All threaded applications are tested against platforms with different cores/processors to identify runtime issues. Formal source-code validation techniques are used to identify potential failures.

4. Utilization. A few developers receive formal training on programming using threads, and how to avoid hazards such as deadlocks and race conditions. Threading considered a programming issue, not a design, requirements or architectural issue. Use of threading encouraged but not mandated, except in performance-intensive routines. Some libraries and runtimes required to support threading. Specific tools to test threaded code are purchased and used from time to time. Some, but not all, threaded applications are tested against platforms with different cores/processors to identify runtime issues. No formal validation of threaded code for correctness.

3. Hotspots. Developers are largely self-taught about threading. Threading used to address known performance trouble spots within applications by applying simple techniques, such as OpenMP, to optimize loops on a desktop application, or the use of thread pools to manage user connections on a server application. Results measured with code profilers and casual benchmarks. Use of threading is allowed, but not particularly encouraged or required. Minimal testing of applications against platforms with different cores/processors to identify runtime issues.

2. Experimentation. Some developers have studied threading, such as by reading articles, but are not trained. Simple tests of threading conducted with trivial or ad hoc projects; some tests will appear to indicate failure, because the tests weren’t properly designed or executed. Some allocation of enthusiast team members’ time is channeled into exploring threading, often as a “skunkworks” project. Some understanding of the different threading models. Minimal incorporation of threading into production code. No testing of applications against platforms with different cores/processors to identify runtime issues.

1. Awareness. General awareness of the potential benefits of threading desktop or server applications, but unsure of the specific benefits of different techniques for threading. Threading not incorporated into the development process. Developers trust that compilers, libraries and runtimes are handling threading automatically. No serious consideration of threading as a way to solve performance problems. No testing of applications against platforms with different cores/processors to identify runtime issues.

0. Unawareness. They don’t know and they don’t care: Developers, architects and managers are either unaware of the existence of threading, or don’t believe that it applies to their software development practices. Completely trust that the operating system handles everything automatically when more cores or processors are added. Nobody is following technical discussions regarding threading. z

(My thanks to SD Times columnist Andrew Binstock, who reviewed an early version of the model, offered ways to make it more generally applicable to both desktop and server development, and suggested adding ThMM stage 0.)

Editor’s Note: For a look at a complementary model proposed by Larry O’Brien, see page 39.

Alan Zeichick is editorial director of SD Times. Read his blog at ztrek.blogspot.com.


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading