[concurrency-interest]Re: Interface Condition - bind/unbind ?!

Alexander Terekhov TEREKHOV@de.ibm.com
Mon, 4 Feb 2002 14:06:01 +0100


[...Condition.await() and Condition.awaitUninterrupibly()...]

Personally, I would greatly appreciate if the level of presented
details/description with respect to condvars/locks/etc would
match (at least ;-) the following***:

http://www.opengroup.org/onlinepubs/007904975/functions/pthread_cond_wait.html
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_cond_signal.html
http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09

regards,
alexander.

[***] Brand new and now official POSIX.1-2001/SUSv3 PDF-links:

http://www.opengroup.org/publications/mem-online/c950/c950.pdf
http://www.opengroup.org/publications/mem-online/c951/c951.pdf
http://www.opengroup.org/publications/mem-online/c952/c952.pdf
http://www.opengroup.org/publications/mem-online/c953/c953.pdf
http://www.opengroup.org/publications/mem-online/c610/c610.pdf

Registration and free membership to get access:

http://www.opengroup.org/austin

regards,
alexander.

---------------------- Forwarded by Alexander Terekhov/Germany/IBM on
02/04/2002 02:02 PM ---------------------------





Alexander Terekhov
02/02/2002 11:56 PM


To:   concurrency-interest@altair.cs.oswego.edu
cc:

From: Alexander Terekhov/Germany/IBM@IBMDE
Subject:  Re: Interface Condition - bind/unbind ?!
Importance:    Normal



> 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