ABSTRACT
ThreadInfo The most important component in our framework, when working with threads, is the ThreadInfo class. In order to be able to uniquely identify a thread, our ThreadInfo class stores a thread name and a thread ID. This information can be used during logging in order to identify which thread wrote which log entry. ThreadInfo also offers methods to wait for a thread, to stop it, or to kill it, although killing a thread should usually be avoided. Another important feature of ThreadInfo is the recording of wait object information. Whenever a synchronization object changes its wait state, it stores that information in the ThreadInfo’s wait object information array. With this information, the ThreadManager is able to construct a complete snapshot of the threading framework’s current state. Additionally, each thread is able to detect whether there are any pending wait operations left before it is stopped (e.g., a mutex might still be locked after an exception occurred). In this case, it can issue a warning as such a scenario could potentially lead to a deadlock. Another feature that we have built into our ThreadInfo objects is active deadlock detection. Using a simple trigger system, we can easily create a watchdog service thread that keeps checking for locked threads. In order for this feature to work, a thread has to continuously call the TriggerThread() method of its ThreadInfo instance. If the gap between the last TriggerThread() call and the current timestamp becomes too large, a thread might be deadlocked. Do not use too small values (i.e., smaller than a second) in order to prevent accidental timeouts. If a thread is known to be blocking, you can temporarily disable the trigger system using the SetIgnoreTrigger() method. You can also use this
method to permanently disable triggering in the current thread in order to avoid the overhead caused by TriggerThread(). ThreadInfo objects are stored and managed by the ThreadManager. For faster access, a reference to each thread’s own ThreadInfo is stored in thread local storage (TLS). The ThreadManager uses our TLSEntry class in order to allocate a storage slot. This storage slot is local to each thread, which means we only have to allocate one slot in order to store a reference for each thread’s ThreadInfo. Another nice feature of the ThreadInfo class is that it provides a great way to easily extend the threading framework, as discussed later.
