Interface Condition - bind/unbind ?!
Sat, 2 Feb 2002 16:40:33 -0500
> Could you please clarify this bit as well?
> (I mean what happens if a thread gets interrupted
> while contending for a *lock*, AFTER consuming a
> signal/timeout, and perhaps the ideas behind
> interruptible *mutex* locking in general...,
> well, interruptible semaphores are OK, but
> mutexes... hmmm)
There are two methods, Condition.await() and
Condition.awaitUninterrupibly(). (And similarly Lock.acquire() and
The awaitUninterrupibly method is like POSIX. I agree that sometimes
you want a completely uncancellable wait, but not often; mainly for
use in recovery code and the like. Otherwise it makes life difficult
for people trying to manage cancellation. See today's other thread.
The plain await() method may throw an InterruptedException only while
waiting to be notified, but must use acquireUninterruptibly upon lock
reacquisition. (See the CondVar class in dl.util.concurrent for one
way to do this.)
You are right that a ReentrantLock class will have to save and restore
lock count, but we make this possible by associating Condition
implementations with their Lock classes, so the implementators can get
at internal lock state to accomplish this.
We will surely nail down the relationships between notification and
interruption very carefully, since the lack of precision about such
things with Object.wait has been a concern of several of us on the
expert group for many years now.