>>>>> "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 correct multithreaded code in any
language." The big difference with Java is that the syntax has been
made pretty trivial, often fooling people into thinking that the
semantics is also simple.
My position is that if the code doesn't run at all (e.g. deadlocks)
under either green or native threads, the code's got a bug.
Prioritization and preemptive multi-threading can be crutches for bad
code - we tend to view with extreme suspicion any code which uses
priorities or says that it requires one model or the other without an
obvious reason.
On the other hand, a kernel-based thread implementation is essential
for getting "fair", "realtime", or "appropriate" scheduling...
Correct prioritization of threads, in particular, is a black art -
quite often it leads to counterintuitive results.
> ... 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 Linux now supports them.
Obligatory Java-Linux subject: What I'd *really* like (for my own
application) is for VMs to support a hybrid of green and native
threads - e.g. a limited pool of natives running a larger set of
greens. Native threads can be awfully expensive - we recently had a
situation where our system started raising out-of-memory exceptions
only under the windows VM: turns out that we had a burst of thread
creation that completely choked the windows native thread system.
Haven't looked at the 1.1.7a diffs yet - anyone working on
something like this for Linux?
cheers,
-mik
--
Michael Thome ([EMAIL PROTECTED])
