The concurrency of threads and the parallelism of the hardware
jointly contribute to the processing speed of programming applications.
With threaded programs, ever on an increase in the industry, it becomes
essential to understand the underlying complexity in implementing
the concept. In addition, this understanding helps you interpret the
results of debugging threaded programs.
The following are the most important concepts that attribute
to the complexity in threaded programming:
Mutual exclusion (mutex) is a method which ensures that the
threads share program resources systematically, thereby avoid unintended
modification of the data in shared variables. Program segments attach
locks to shared resources. This ensures mutual exclusion. Improper
mutex lock-unlock in threaded applications could result in a deadlock
condition which stops the program execution completely.
Race condition arises when shared data or resources are not
accessed in any particular order thus resulting in inconsistent data
in some instances. This possibility occurs when you write code segments
without ensuring serial access to shared resources. Such threaded
programs with inconsistent and random access to shared variables contribute
to the complexity involved in debugging threads.
In addition, when a high-priority thread waits for a lock which
a low-priority thread holds, the priority inversion here results in
lesser execution efficiency.
Thread programs, prone to such complexities, are subject to
conditions or events that reduce efficiency or increase the potential
for errors.
Common conditions or events in thread programming |
 |
The following are the most common conditions or events in thread
programming that could lead to errors:
The thread attempts to acquire a non-recursive mutex
that it currently holds.
The thread attempts to unlock a mutex or a read-write
lock that it has not acquired.
The thread waits on a mutex or a read-write lock that
is held by a thread with a different scheduling policy.
Different threads non-concurrently wait on the same
condition variable, but with different associated mutexes.
The thread terminates execution without unlocking
the associated mutexes or read-write locks.
The thread waits on a condition variable for which
the associated mutex is not locked.
The thread terminates execution, and the resources
associated with the thread continue to exist in the application because
the thread has not been joined or detached.
The thread uses more than the specified percentage
of the stack allocated to the thread.
The number of threads waiting on any pthread object
exceeds the specified threshold number.
HP Wildebeest Debugger (WDB) offers advanced thread debugging
features to support debugging of threaded applications and detection
of these conditions.
