David Wall wrote:
>
> >This makes me wonder.
> >AFAIK, according to their definition, threads are supposed to be
> "lightweight"
> >processes.
I think a lot of people are getting hung up on the notion of lightweight
vs heavyweight processes. Here's the quick definition of the
differences, followed by an explanation of why it's not really relevant
to this discussion:
- Heavyweight processes run in separate address spaces
- Lightweight processes run in the same address space
The added weight of heavyweight processes come from the system resources
consumed by more real and virtual memory -- that's what's meant by
"lightweight" vs "heavyweight". When apps start to get big and flog
memory (especially if they flog memory in ways that stress cache and
VM), the light vs heavy distinction really starts to matter. All that
other discussion about Linux process table slots and implementation
details is interesting, but not really relevant to the distinction
between light and heavy.
At any rate, that distinction doesn't matter in the discussion of Java
threads. Both thread models run in a single address space. The niggling
details -- how threads get switched, use of process table slots, and how
well (if at all) preemption happens -- do have implications on
performance, capacity, and interactivity (perceived performance). But
I'll bet that it wouldn't take a lot of effort to write two benchmarks,
one conclusively showing that green threads are faster, and the other
doing the same for kernel threads.
Here are my (admittedly personal) reasons you'd want to use kernel
threads:
1) Take advantage of multiprocessors if you've got them
2) Native-thread preemption is more likely to happen in a way that
improves interactivity (but don't bet product sales on it!)
3) Native-thread preemption is likely to stress-test your program more
effectively
Here are the reasons you wouldn't:
1) They don't work yet :-)
2) Your code is dependent on the gentle, friendly preemption (or
non-preemption) you get from green threads and is broken by kernel
threads
Nathan Meyers
[EMAIL PROTECTED]
