Intel Threading Building Blocks

When to Use Mutual Exclusion

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 ...