Sylvia Else wrote:
[...]
> I felt there was a consensus to the effect that they
> shouldn't be lost. The lack of consensus related to
> how this might be achieved.
In POSIX, notification shouldn't be lost in the case
of thread cancelation. In general, that means that
implementations *broadcast* the condvar on behalf of
the canceled waiter. OTOH, a timed wait is allowed to
consume a signal. It's up to the application to either
recheck the predicate and ignore timedout status (if
it turns out that wait is satisfied), or reissue
notification using either pthread_cond_signal() or
pthread_cond_broadcast(). Also, note that lost signal
problem just can't occur if ALL signalers ALWAYS use
pthread_cond_broadcast()... and this is the case with
multiple predicates associated with the same condvar.
The problem with notify() used to reissue stolen
notifications is that a condvar could be associated
with multiple predicates at the time of reissuing...
but NOT at the time of "original" notify(). That is
the main reason why notify() just can't be used to
reissue stolen notifications. I'm pretty sure that
notifyAll() is the only "right" way to reissue lost
notifications (in the case of thread interruption).
> The draft talks about "when a notification and an
> interruption action execute at approximately the same
> time".
In POSIX, pthread_cond_{timed}wait() is "shall occur"
cancelation point. OTOH, since spurios wakeups are
allowed at any time (meaning that "waiter" may either
be waiting... or contend for the mutex and THAT thing
just can't be canceled) you can't really be sure that
cancelation request will be delivered to your victim
that called pthread_cond_{timed}wait() BEFORE you've
canceled it. The guarantee is that it shall occur if
pthread_cond_{timed}wait() (already expired timeouts
aside for a moment) is called AFTER pthread_cancel()
invocation. So, you'd need some form of sync (in order
to resolve the race) to "detect" any broken impl, I'm
afraid. Well, here's a quote from POSIX Rationale:
<quote>
Races Between Cancellation and Resuming Execution
Due to the nature of cancellation, there is generally
no synchronization between the thread requesting the
cancellation of a blocked thread and events that may
cause that thread to resume execution. For this reason,
and because excess serialization hurts performance,
when both an event that a thread is waiting for has
occurred and a cancellation request has been made and
cancellation is enabled, IEEE Std 1003.1-2001
explicitly allows the implementation to choose between
returning from the blocking call or acting on the
cancellation request.
</quote>
regards,
alexander.
Sent by: owner-javamemorymodel@cs.umd.edu
To: javamemorymodel@cs.umd.edu
cc:
Subject: Re: JavaMemoryModel: No decision on lost notifications
At 04:52 PM 5/08/2003 -0400, Bill wrote
>It didn't seem that any clear consensus was reached on lost
notifications.
>If someone else wants to lead the charge on doing the cat herding on
this,
>feel free, but do it quickly. My current plans are to not make any
>requirements on lost notification in JSR-133.
I felt there was a consensus to the effect that they shouldn't be lost.
The
lack of consensus related to how this might be achieved.
The draft talks about "when a notification and an interruption action
execute at approximately the same time". There will have to be a
significant clarification of what "approximately" means in this context.
Sylvia.
-------------------------------
JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:50 EDT