> -----Original Message-----
> From: Bill Pugh [mailto:pugh@cs.umd.edu]
> I understand that the issue is a little bigger than I had spoken of
> earlier; putting fairness into Java semantics will prohibit any pure
> non-preemptive JVM (e.g., a VM in which "while (true);" halts the
> entire VM).
>
> I am willing to go either way on this. Allowing "while (true);" to
> halt the entire VM is rather unpleasant, but it may be too difficult
> to force all VM implementors to use some form of preemption.
This is completely outside the scope of the JMM JSR. The JLS allows for
"while(true);" to halt the progress of an application running in the VM.
That is it, pure and simple - end of story.
I have absolutely no problem with this style of scheduler - it is a
perfectly valid scheduling model. The two basic rules of concurrent
programming are to assume that interleaving can happen at any time, but
never to require it. This forces you to always use synchronization to
protect shared data, and to always use some form of inter-thread
communication to ensure progress. That's the key to portable
multi-threading.
That said we validly write applications that are intended to be run on
particular VM's on particular systems, which exhibit runtime characteristics
that are deemed favourable - e.g. use of native threads and multiprocessors.
If a VM provides a basic scheduling model that supports native threads and
multiprocessors, but in which these transformations make it seem as if it is
employing a different scheduling model, then that is a quality of
implementation issue. The people writing big server apps are not "joe
average" programmer, but competent programmers trying to get the most out
their environment and will very quickly and pointedly make it known that the
change in behaviour is not welcome.
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:35 EDT