Threading and Sanity

Threaded code is expensive - it takes longer to write and is harder to debug. Here are some of the things I try to do to keep myself sane while working on threaded code.

• Only thread when there is a need for threading. Threading is a way to capture CPU performance. I consider threading as a way to meet performance goals, not as a default.

  This also means not trying to thread code that is either not performance critical or isn't burning up enough CPU to be worth it. The less code is threaded, the cheaper the app is to develop, so better to only thread the "big fish".

• The main thread handles flow control. A number of different graphic and UI APIs require access only from the main thread, so a natural extension of this design (particularly in a game with a sequential render-loop).

  The requirement to run on the main thread simplifies some synchronization issues because certain API calls into an object will be "naturally exclusive" due to their main-thread requirement. A debug macro catches illegal calls to these functions from the wrong thread.

• Message queues for resource ownership. With this idiom, an object can have only one owning thread - the ownership is transferred via thread-safe message queues. Because the message queue is a synchronizer, no locks are required and no dead-locks can occur.