A Note on the Threading Model

Multi-threading is a powerful and common tool for improving the concurrency of programs. Once an engineer has grasped the concept of threads, however, the beginner's fearful avoidance of this idea is often replaced by overuse.

Overuse of threading creates many problems — including performance degradation. While multiple threads might seem a difficult approach, the popular models are actually oversimplified (e.g. thread-per-request), and can have poor performance. More complex concurrency solutions (thread pools, the ACEProactor pattern [Hu98], asyncore [Ros02]) are often required.

By far the biggest concern when using multiple threads, however, is data integrity and the consequences of locking. Mistakes in thread synchronization lead to bugs almost as subtle and dangerous as the infamous C++ dangling reference. In Open Source projects, which may be worked on a very large and diverse group of people, this is a particular problem.

Once the ideas of threading are grasped, adding threads is easy. The true challenge is actually to minimize and control the use of threads, so that reliability as well as performance are not adversely affected.

The MVM application (which forms the basis of the Flightdeck-UI monitoring solution) tries to avoid threads for the above reasons (they may also not be available on all platforms). Within the MVM architecture, a good place for adding concurrency is in the expansion modules such as MVMurllibCmd.

The above approach to concurrency effectively quarantines these issues to a well-defined area of the program. If problems arise, there is only one place to look. A similar defensive technique is effective in C++ memory allocation (which is another reason why the Factory design pattern is such a good idea).