In this chapter, we will look into some of the more advanced issues related to data synchronization. When you write a Java program that makes use of several threads, issues related to data synchronization are those most likely to create difficulties in the design of the program, and errors in data synchronization are often the most difficult to detect, since they depend on events happening in a specific order. Often an error in data synchronization can be masked in the code by timing dependencies. You may notice some sort of data corruption in a normal run of your program, but when you run the program in a debugger or add some debugging statements to the code, the timing of the program is completely changed, and the data corruption no longer occurs.
Programmers with a background in a particular threading system generally tend to use terms specific to that system to refer to some of the concepts we discuss in this chapter, and programmers without a background in certain threading systems will not necessarily understand the terms we choose to use. So here’s a comparison of particular terms you may be familiar with and how they relate to the terms in this chapter:
- Barrier
A barrier is a rendezvous point for multiple threads: all threads must arrive at the barrier before any of them are permitted to proceed past the barrier. Java has no barrier class, but we implemented one in Chapter 5.
- Condition variable
A condition variable is not actually a lock: it is a variable associated with a lock. Condition variables are often used in the context of data synchronization. Condition variables generally have an API that achieves the same functionality as Java’s wait and notify mechanism; in that mechanism, the condition variable is actually the object the lock is protecting. We implemented a condition variable in Chapter 5.
- Critical section
A critical section is the same as a synchronized method or block. Critical sections do not nest like synchronized methods or blocks.
- Event variables
- Lock
This term refers to the access granted to a particular thread that has entered a synchronized method or a synchronized block. We say that a thread that has entered such a method or block has acquired the lock. As we discussed in Chapter 3, this lock is associated with either a particular instance of an object or a particular class.
- Monitor
A generic synchronization term used inconsistently between threading systems. In some systems, a monitor is simply a lock; in others, a monitor is similar to the wait and notify mechanism.
- Mutex
Another term for a lock. Mutexes do not nest like synchronized methods or blocks and generally can be used across processes at the operating-system level.
- Reader-writer locks
A lock that can be acquired by multiple threads simultaneously as long as the threads agree to only read from the shared data, or that can be acquired by a single thread that wants to write to the shared data. Java has no reader-writer locks, but we’ll develop a reader-writer lock class later in this chapter.
- Semaphores
Semaphores are used inconsistently in computer systems. Many developers use semaphores to lock objects in the same way Java locks are used; this usage makes them equivalent to mutexes. A more sophisticated use of semaphores is to take advantage of the counter associated with them to nest acquisition to the critical section of the code; Java locks are exactly equivalent to semaphores in this usage. Semaphores are also used to gain access to resources other than code; the example of acquiring resources that we showed in the ResourceThrottle class in Chapter 4 implements this type of semaphore behavior.