Book Errata

Page 33, bottom.
Each time a one-point crossover operation is performed, the crossover point is chosen randomly.
Page 54.
``If a thread in the running state calls its yield method, it gives up the CPU and is put back in the runnable set in the runnable state.'' Even if several threads are runnable, there is no guarantee that the next thread to run on the CPU is not the one that just yielded.
Page 55.
``The Java thread scheduler ensures that the highest priority runnable thread (or one of them if there are several) is running on the CPU.'' This is not accurate. According to page 415 of The Java Language Specification [21], the scheduler usually ensures this, but it is not guaranteed that the highest priority thread is always executing on the CPU.
Page 57.
Thus Library Class 3.2 (Scheduler) does not guarantee time slicing, but it works in practice.
Page 106, 121.
The commands to induce starvation should be (change -n5 to -p5)
     javac dphi.java dpdr.java
     java DiningPhilosophers -p5 -R300 1 100 10 1 1 100 100 1 100 1
     
Page 135.
If several threads are blocked, waiting to acquire the lock on an object that is currently held by some other thread, there is no guarantee that the thread waiting the longest will be the next one to acquire the lock when it is released.
Page 137.
A notify() removes an arbitrary thread from the wait set, if there is one. The thread must reacquire the monitor lock and therefore competes with all other threads trying to acquire the monitor lock, having called a synchronized method, or reacquire the monitor lock, having been notified. Thus the notified thread is not necessarily in the runnable (ready) set, but might still be blocked.
Page 393.
The interrupt/notify race condition is still present. Suppose several threads are blocked in wait() inside P(). Next, suppose one is notified by a thread calling V(). The notified thread is removed from the wait set and now needs to reacquire the monitor lock in order to continue execution in the monitor. Now suppose the notified thread is interrupted before reacquiring the monitor lock. An InterruptedException exception is thrown and the thread executes its catch block when it reacquired the monitor lock. However, value is less than zero, so the thread does another wait and the notify is lost.
Page 399.
A similar problem to page 393.


SJH
shartley@mcs.drexel.edu