m.unlock();
}
public void writeLock() {
m.lock();
nWaitingWriters++;
while ((owner != null) || (nCurrentReaders > 0)) {
writersCV.condWait(m);
}
nWaitingWriters--;
owner = Thread.currentThread();
m.unlock();
}
public void unlock() {
m.lock();
if (owner != null) {
owner = null;
} else
nCurrentReaders--;
if ((nWaitingWriters > 0) && (nCurrentReaders == 0)) {
writersCV.condSignal();
} else {
if ((nWaitingWriters == 0) && (nWaitingReaders > 0)) {
readersCV.condBroadcast();
}
}
m.unlock();
}
}
Priority Inheritance Mutexes
Should a high-priority thread (T2 in Figure 7-3) be blocked, waiting for a lock that is held by
another thread of lower priority (T1), it may have to wait a longer time than seems reasonable,
because a third thread (T3) of middling priority might be hogging the CPU. To do justice to
overall system performance, it would be reasonable to elevate the scheduling priority of T1 to the
level of the blocked thread (T2). This is not done for normal Pthread mutexes, so user programs
may suffer from priority inversion. In POSIX, priority inheritance is an option during mutex
initialization and is probably useful only in realtime situations. Java, by contrast, is very
specifically not designed for realtime work, rendering the question of PI mutexes moot. You could
write them, but it's very doubtful that they would be useful.
Figure 7-3. Priority Inversion
Search WWH :
