To prevent race conditions and other nondeterministic and undesirable behavior, no two tasks should invoke a method or function concurrently on the same objects.
In other words, you need to provide your own locking. When planning the program’s division of labor, try to stick to intuitively obvious locking. Threading Building Blocks provides a lot of help, but it cannot always hide the necessary locking.
Leaving the control to you in parallel programming is important because locking more often creates overhead, which will often lead to poor scalability. In general, you should work to divide data among tasks so tasks implicitly have exclusive access to individual objects and thereby avoid any chance of concurrent updates. When you cannot do so, use fine-grained locking so that you hold a lock for as little time as possible.
When can intuition fail us, and the intuitively obvious not be obvious enough? When reads are not what they seem and actually modify some state. It is okay for concurrent uses of objects if all uses are strictly for reading and do not modify any state. Here are two cases where something seems like a read but is not and must be controlled by mutual exclusion:
- Objects that share internal state
An example is string structures that have different string objects point to a shared string buffer if the actual string values are the same or overlap. The objects in these cases must protect themselves internally to prevent the creation of race conditions due to lack of control.
- Structures where reads track usage
Beware of any exotic objects you might design or use that modify state when used. An example is a self-balancing binary search tree structure (splay tree) where a read access can cause internal modifications of the data structure.
Descriptions of the classes in this book note any departures from the need for synchronization. For example, the concurrent containers are more liberal. By their nature, they permit concurrent operations on the same container object.
This chapter assumes that you understand the importance of mutual exclusion and when it is needed. This chapter will define a few concepts as it goes along to show how Intel Threading Building Blocks fits the requirements, but it won’t spend time on tutorials about locking.
Threading Building Blocks offers two kinds of mutual exclusion:
- Mutexes
These will be familiar to anyone who has used locks in other environments, and they include common variants such as reader-writer locks.
- Atomic operations
These are based on atomic operations offered by hardware processors, and they provide a solution that is simpler and faster than mutexes in a limited set of situations. These should be preferred when the circumstances make their use possible.