You need to think about whether concurrent accesses to the same resources will occur in your program. The resource with which you will most often be concerned is data held in memory, but you also need to think about files and I/O of all kinds.
The best policy is to decompose your problem in such a way that synchronization is implicit instead of explicit. You can achieve this by breaking up the tasks so that they can work independently, and the only synchronization that occurs is waiting for all the tasks to be completed at the end.
Instead of locks, which are shown in Figure 2-14, you can use a small set of operations that the system guarantees to be atomic. An atomic operation is equivalent to an instruction that cannot be interrupted.
When explicit synchronization and atomic operations are insufficient, locks needs to be used. Chapter 7 covers the various options for mutual exclusion.
Consider a program with two threads. We start with X = 44. Thread A executes X = X + 10. Thread B executes X = X - 12. If we add locking (Figure 2-14) so that only Thread A or Thread B can execute its statement at a time, we end up with X = 42. If both threads try to obtain a lock at the same time, one will be excluded and will have to wait before the lock is granted. Figure 2-14 shows how long Thread B might have to wait if it requested the lock at the same time as Thread A but did not get the lock because Thread A had it first.
Without the locks, a race condition exists and at least two more results are possible: X = 32 or X = 54. X = 42 can still occur as well (Figure 2-15). Three results are now possible because each statement reads X, does a computation, and writes to X. Without locking, there is no guarantee that a thread reads the value of X before or after the other thread writes a value.
