Presenting the Threading Maturity Model (ThMM)

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 this week with James Reinders, director of marketing and business for Intel’s Software Developer Products Group (that is, the compiler folks), I suggested a Threading Maturity Model (ThMM), as analogous to things like the Capability Maturity Model, or the SOA Maturity Model. James liked the idea, and I’m presenting it here for comment. As far as I know, this is an original concept.

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 non-threaded 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 hazard 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 trusts that the operating system handles everything automatically when more cores or processors are added. Nobody is following technical discussions regarding threading.

(My thanks to James Reinders for his enthusiastic response, and to my colleague Andrew Binstock, who reviewed an early version of the model. Andrew offered ways to make it more generally applicable to both desktop and server development, and suggested adding ThMM stage 0.)