Interface Condition - bind/unbind ?!
Fri, 1 Feb 2002 21:06:16 -0500
> Why would an explicit way (without a need to "re-initialize")
> to *change* the associated lock would make some problems with
> respect to errors (error checking) and/or efficiency?
If rebinding were a standard feature, I would expect/want an
IllegalStateException if I attempted to rebind the condition while a
thread was in the midst of waiting on it. This adds state-tracking
overhead. Also, to conform to memory model, the internal field
recording the owner lock would at least need to be volatile (rather
than final), or maybe even use an inner lock to access both the owner
lock and execution state to make sure they are in sync.
You could get away with a lighter version if you use it in code that
you know either won't misbehave or don't care what happens if it does.
But I'm very hesitent to build this functionality into a library class
that hopefully thousands of programmers of varying abilities will use.
By not allowing rebinding, we can make usage both simpler and faster.
I might change my mind if I knew of a really compelling use case though.