Nathan Meyers wrote:
>
> 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.
>
This was a really relevant piece of info and brings us to what I think is
the point of the discussion ;-}
>
> 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.
I do believe that execution speed is not always the critical factor in
threading.
Concurrency and system resources manipulation is the issue raised here.
What I believe was that green threads (I used to know them as user space
threads) fail to provide with real concurrency when there are
computationally heavy operations involved, and you do not provide with an
explicit (simple terms: yield by time to time) or implicit (eg listening
for sockets) scheduling mechanism.
My main concern is that I (and many others as I understand) usually fire up
threads left and right to do the computation (and sometimes use some CPU
time consuming loops for heavy computation). What I have observed is that
concurrency breaks, and degrades into a form of sequential execution (which
is not exctly the desired effect) - not to mention GUI manipulation
glitches, if they work at all.
But it is not a right thing to bring the system kernel to its limit by
firing up threads for computation, and this is how I understand the
difference betwen threads and processes, and the distinction between light
and heavy.
It would really be a sad think if linux threads are not really light (but
absolutely normal processes that don't even share the same address
space)and bring the kernel to its process limit.
>
>
> Here are my (admittedly personal) reasons you'd want to use kernel
> threads:
>
> 1) Take advantage of multiprocessors if you've got them
java is supposed to know nothing of SMP ;-} (but it helps if present)
>
> 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 :-)
sad to say, but it is true...
>
> 2) Your code is dependent on the gentle, friendly preemption (or
> non-preemption) you get from green threads and is broken by kernel
> threads
>
I deduce that we shouldn't relly on the VM to do the scheduling, since it
is not known if it will. (and this breaks another myth: in java, even
threads are easy to handle ;-} )
thanx for your attention,
Dimitris
