xplicitly _un_specified.
>...and so code that runs
> differently with kernel threads or user threads is not "correct Java".
I don't know if you can say that, but it is code that isn't written
well enough to accounts for the differences allowed by the undefin
> Michael Thome writes:
Michael> Obligatory Java-Linux subject: What I'd *really* like
Michael> (for my own application) is for VMs to support a hybrid
Michael> of green and native threads - e.g. a limited pool of
Michael> natives running a larger set of greens. Native threads
> "Nelson" == Nelson Minar <[EMAIL PROTECTED]> writes:
>> (b) kernel thread semantics are different from user thread semantics,
> In practice, Java threads are woefully underspecified, and so it's
> nearly impossible to write correct multithreaded Java.
I'd say it is "difficult to write cor
> In practice, Java threads are woefully underspecified, and so it's
> nearly impossible to write correct multithreaded Java. This is the
> most serious deficiency in Java. I agree, kernel threads (with
> preemption and real priority scheduling) is the right way to go, and
> I'm glad to see that
>(a) Most of the other unix implementations use kernel threads now
>(Solaris, AIX, Digital Unix),
Really? Cool.
>(b) kernel thread semantics are different from user thread semantics,
Technically, there is only one semantic for Threads in Java. In theory
Java is a completely specified runtime,
