Interface Condition - bind/unbind ?!

Alexander Terekhov TEREKHOV@de.ibm.com
Sat, 2 Feb 2002 20:46:03 +0100


> > 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.

Yes, I see it now, thank you! I think that I've just got
used too much to C/C++ way of placing "undefined" behaviors
all around. ;-) I guess the same/similar considerations
would speak against having totally "unbound" - Pthread-style
condition variables, right?

I have one more question, though...

I am just struggling to understand how Java conditions
are supposed to work together with "java.util.concurrent.Lock"s,
given that in Pthreads, condvars only work with *mutexes*
(including recursive, but IFF lock count == 1, AFAIK),
which *do NOT throw on lock/acquire operation* (I mean
Pthread thread cancellation[1], which, BTW, due its[2]
rather simple (AFAIK) always-rethrow/stopping-is-illegal
nature, I personally like somewhat more than Java's
"interrupt" model, IMHO)

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)

Thanks!

regards,
alexander.

[1] a lock/mutex is re-acquired even if awaiting
    thread gets canceled (or timedout), to allow
    shared data cleanup -- "waiters count" or
    something like that.

[2] including pthread_exit()



Doug Lea <dl@cs.oswego.edu>@altair.cs.oswego.edu on 02/02/2002 03:06:16 AM

Please respond to dl@cs.oswego.edu

Sent by:  concurrency-interest-admin@altair.cs.oswego.edu


To:   concurrency-interest@altair.cs.oswego.edu
cc:
Subject:  Re: Interface Condition - bind/unbind ?!




> 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.


-Doug

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest