Just a few follow ups ...
Rodrigo wrote:
> allow spurious wakeups (SW) (community review 2) model
...
> -STRONG: it breaks code. it does, my otherwise correct code
> at least, and probably common code involving many posible
> waiters and a notifyAll. it is not true that using
> no-priority monitors forces you to use the "signals as
> hints" paradigm, some code can be simpler and faster without it.
I'm not sure what you are referring to here. The only code the
spurious wakeups can break is code that uses "if (!condition) wait()"
rather than "while (!condition) wait()".
"signals as hints" I assume refers to notify() being an optimisation
compared to notifyAll(). It is a fact that correct use of notify()
requires that certain conditions be met. If your code meets them
that's fine. I'm not sure what point you are trying to make here.
> -as i posted before, due to SW it seems impossible to make
> any multithreaded java program that uses wait/notify and is
> guaranteed to ever run. it complicates or makes it
> impossible to define any useful form of progress guarantee.
Java's scheduling rules make it near impossible to give progress
guarantees. But I agree that trying to model SW's - where the SW could
occur infinitely often - would be a problem.
> how would SW fit in into runtime java??
VM's do not have to provide spurious wakeups just because the spec
allows for them and applications should be prepared to handle them.
;-)
> i belive most
> programmers will avoid interrupting their own code, rather
> they would signal termination by the more mundane and
> ordinary interthread communication means they are
> accustomed to use
In Java Thread.interrupt() is that more mundane and ordinary
interthread communication mechanism. I'm curious what other mundane
mechanisms would allow you to communicate with a thread that is
blocked doing a wait ?
> terminate code written by others (and also native code i
> guess- never used JNI, can native code respond to ints?).
JNI can query interrupt status just like Java code can. A native call
that blocks in native code is unlikely to be unblocked by the
interrupt.
> restricted spurious wakeups model
>
> in the spec, restrict in which cases SW are legal (ie: in
> the presence of interrupts and all that).
This is an incomplete proposal. Exactly what cases for SW should be
legal?
I would not want to encourage people to write code that only worked
correctly when interrupts were not involved. There are enough problems
with code swallowing interrupts.
> allow lost notifications model
>
> allow LN when a thread is interrupted after being notified.
> i can't see why EVERYBODY has rejected this. am i missing
> something?
Allowing lost notifications introduces all of the problems that late
notify had but now the application programmer is the one that has to
fix it. If lost notifications were permitted then every piece of code
that uses wait() and which wants to be responsive to interrupts, would
have to include a catch clause that tries to deal with the potential
for a lost notification. Without keeping a count of waiting threads
that would mean re-issuing a notify() (or notifyAll()) and hence cause
spurious wakeups.
This is not a good programming model to present to the programmer. Why
should every programmer have to fix this problem?
> -would it be fair to say that code broken by this model
> would probably also be broken by SW anyway?
No. Code that simply allows the IE to propagate would be broken under
this model but is not broken with SW. Code written to deal with this
model would need to use a while loop as SW-safe code would.
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:55 EDT