David Holmes wrote:
[...]
> > http://opengroup.org/austin/mailarchives/austin-review-l/msg
> > 01561.html
>
> :) I side with Patrick and Caspar on that one.
Just to make it clear, I side with David (S.), of course. ;-)
I don't think that timedout waiters should be disallowed to
"steal" signals. Cancelation/IE is different, though. The
problem is that it could burden implementers and also could
increase the amount of spurious wakeups. OTOH, programmers can
easily insert their own signaling (either notify or notifyAll,
depending on their program logic). To illustrate it a bit,
here's an example of "implementation" that does NOT allow for
waiters to steal signals with respect to both cancelation and
wait timeouts. (a futex-emu beast can steal signals but futex-
CV should not). <the most relevant bits>
http://www.terekhov.de/DESIGN-futex-CV.cpp
....
bool timedwait(int value, const timespec & abstime, bool & stolen_sig) {
mutex::guard guard(m_mutex);
if (value == m_value) {
waiter this_waiter(m_queue);
do {
if (m_condvar.timedwait(guard, abstime)) {
// timestamps aside for a moment...
stolen_sig = this_waiter.is_reset();
return true;
}
} while (!this_waiter.is_reset());
}
return stolen_sig = false;
}
....
waiter(futex_condvar * fcv, mutex & mtx) :
m_fcv(fcv), m_mtx(mtx), m_ftx(fcv->enter_wait(mtx)), m_sig(true) {
}
~waiter() {
m_fcv->leave_wait(m_ftx, m_sig);
m_mtx.lock();
}
....
void leave_wait(int ftx, bool stolen_sig) {
mutex::guard guard(m_mutex);
if (ftx != m_futex) {
assert(m_waiters[0]);
--m_waiters[0];
if (0 != m_wakeups &&
0 == --m_wakeups &&
EOC() == m_futex ) {
m_futex = (m_futex < 0) ? 0 : MIN;
m_waiters[0] = m_wakeups = m_waiters[1];
m_waiters[1] = 0;
m_futex.wake(ALL);
return;
}
}
else {
--m_waiters[EOC() == ftx];
}
if (stolen_sig && m_waiters[0] > m_wakeups) {
++m_futex;
m_wakeups = m_waiters[0];
m_futex.wake(ALL);
}
}
....
bool timedwait(mutex & mtx, const timespec & abstime ) {
waiter this_waiter(this, mtx);
return m_futex.timedwait(this_waiter.ftx(), abstime,
this_waiter.m_sig);
}
....
I'd rather not bother myself with respect to timeouts...
regards,
alexander.
P.S. I may be missing and/or misunderstanding something, of course.
To: Alexander Terekhov/Germany/IBM@IBMDE
cc: "jmm" <JavaMemoryModel@cs.umd.edu>, "Doug Lea" <dl@cs.oswego.edu>
Subject: RE: JavaMemoryModel: Spec on on wait and interrupts
Alexander Terekhov wrote:
> David Holmes wrote:
> [...]
> > notify() is sufficient.
>
> Probably not.
That depends on the definition of "sufficient". But I'm inclined to
agree with you - the hole is an unnacceptable (to me) change in the
semantics and that would require either that the VM not let an
interrupted thread consume a notify, or else a notifyAll() must be
performed.
Looks like this issue is reopened.
> > That seems to preclude the problem to me - but words
> > are always open to interpretation.
>
> Yeah. Pls take a look at:
>
> http://opengroup.org/austin/mailarchives/austin-review-l/msg
01561.html
:) I side with Patrick and Caspar on that one. But the very fact a
debate occurred means the spec needs changing to clarify the intent.
But the problem with prose based specifications is that they are
always subject to interpretation and the more words you add to clarify
things the more words that might be interpreted differently.
The annoying thing is that it is the uncertainties of the underlying
pthread and OS primitives that has caused the uncertainties to appear
at the Java/JVM level. :(
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:49 EDT