Most Read Latest News Blog Resources

Following the Maturity Model Thread




February 15, 2007 — 
Alan Zeichick’s proposal of an organizational Threading Maturity Model (see page 36) is an excellent contribution. An organizational model is necessary because, as with object orientation, it does not suffice for a single person to have mastery or near-mastery; the average ability of the team must be at least fair in order to maintain quality. However, the ThMM isn’t very descriptive of individual progress and does not provide guidance. I thought that I’d take a crack at a complementary Personal Thread Maturity Model (PTMM).

A draft of this model drew the comment that what’s needed is the elevation of parallelism to a first-class language concern. I am wholly in agreement. Even so, I doubt that any single concept will suffice for those seeking to maximize the work of their processors in the many-core era. I welcome comments on the PTMM, especially about whether it is too wedded to mainstream languages.

THE PERSONAL THREAD MATURITY MODEL (PTMM)
1. Unaware: Single-threaded, may occasionally use threaded libraries unawares.

Here, there’s no conscious use of concurrence at all. Since no mainstream language makes threads a first-class concern, threads are side effects in library and infrastructure calls. No useful recommendations can be made for programmers in this category, as by definition they are not part of the conversation.

2. Casual: Conscious use of high-level abstractions (components, libraries) to solve specific problems.

Most programmers are here, and are aware of threads and their ability to run a lengthy calculation or IO operation while maintaining a responsive UI. They may use a drag-and-drop component or a Thread object that allows a calculation to run to completion. Their experience with threading is positive: The UI remains responsive, the network calls back, etc. They may be taken aback by the dire warnings about multithreading that are so common to discussions.

Recommendations: Become comfortable with callbacks and async patterns (in .NET, the Event-based Asynchronous Pattern). Avoid known trouble spots: Don’t update the UI from a worker thread, don’t rely on shared data maintaining its state, don’t roll your own sync techniques. I call this “the simplest multithreading that could possibly work,” and it often does. Be vigilant for intermittent errors and performance “traffic jams.”

3. Rigid: Significant use of multiple cores, coordination based on locking.

Programmers now actively exploit threading. Asynchronous processing becomes an intentional part of design. They face their first wicked problems and gnarly bugs and become initiates in the “threading is hard” camp. Designs use locking to coordinate their programs; while programmers may occasionally use other techniques, locking is the hammer with which they pound the nail of concurrency.

Recommendations: The problem for this group is complacency. They’ve triumphed over problems and may have reached a plateau. They discover that core logic is often nonparallel and, although willing, may have a difficult time seeing places where asynchrony can contribute. At this level of mastery, it may not be clear on today’s hardware that further learning is necessary. Since few many-core machines are available, and few of us have access to parallel clusters, moving beyond this level of maturity is driven more by faith and reading than by hands-on experience.

4. Flexible: Attempt to maximize use of cores, use of lock-free algorithms and data structures.

There’s a deeper theoretical understanding of asynchronous processing, mastery of basic techniques, and determination to achieve the best results possible. Programmers seek not just to exploit processors, but to saturate them. This stage is characterized by a shift from programming language-based thinking to hardware-based thinking.

Recommendations: This is a very difficult phase to move through. Popular texts will not guide you past this stage, advancement requires a combination of textbook theory, hardware knowledge and hands-on experience. (I’m not going to claim to have moved beyond this phase myself.)

5. Optimizing: Optimal use of parallel architecture.

Parallelism is fully incorporated into one’s mental approach to solving problems via symbols. Specific techniques are considered not along any “better-worse” axis, but for their individual benefits and drawbacks. Multiple approaches may be incorporated into a single design.

Today, those who have achieved the “Optimizing” level of parallel programming mastery are vanishingly rare. During the days, they are locked deep inside telecom buildings, research facilities and hardware companies.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
 
 
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
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

4/12/2010 to 4/14/2010
Las Vegas
Penton Media

4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

4/19/2010
New York City
Flagg Management

4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG