Interface Condition - bind/unbind ?!

Alexander Terekhov TEREKHOV@de.ibm.com
Sat, 2 Feb 2002 23:56:21 +0100


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

hmmm... here is the POSIX Rationale:

"There are several important blocking routines that
 are specifically not made cancelation points:
 - pthread_mutex_lock()
 If pthread_mutex_lock() were a cancelation point,
 every routine that called it would also become a
 cancelation point (that is, any routine that touched
 shared state would automatically become a cancelation
 point). For example, malloc(), free(), and rand()
 would become cancelation points under this scheme.
 Having too many cancelation points makes programming
 very difficult, leading to either much disabling and
 restoring of cancelability or much difficulty in trying
 to arrange for reliable cleanup at every possible
 place.
 Since pthread_mutex_lock() is not a cancelation point,
 threads could result in being blocked uninterruptibly
 for long periods of time if mutexes were used as a
 general synchronization mechanism. As this is normally
 not acceptable, mutexes should only be used to protect
 resources that are held for small fixed lengths of time
 where not being able to be canceled will not be a problem.
 Resources that need to be held exclusively for long periods
 of time should be protected with condition variables.
 - pthread_barrier_wait()
 Canceling a barrier wait will render a barrier unusable.
 Similar to a barrier timeout (which the standard developers
 rejected), there is no way to guarantee the consistency
 of a barrier's internal data structures if a barrier wait
 is canceled***.
 - pthread_spin_lock()
 As with mutexes, spin locks should only be used to protect
 resources that are held for small fixed lengths of time where
 not being cancelable will not be a problem."

Also, it is my understanding that in POSIX, cancellation
points do not throw once the process is already underway.

> See today's other thread.

You mean Executor stuff? Well, I am moving very slowly ;-)
I am still on the level of locks and condvars! ;-) For
example, general semantics/interactions/use-cases for
waiting and signaling on condvars associated with
read{write}locks, semas (in "non-mutex" mode), etc
is still in total darkness for me. :(

regards,
alexander.

[***] This, I guess, explains why you have
      boolean CyclicBarrier.isBroken() and
      BrokenBarrierException.


Doug Lea <dl@cs.oswego.edu>@altair.cs.oswego.edu on 02/02/2002 10:40:33 PM

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 ?!




Alexander wrote:

> 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
Lock.acquireUninterruptibly())

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.

-Doug

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