The difference between "green" threads and "native" threads is that in the
latter the operating system provides for thread support while in the former
the application, in this case a JVM, builds its own thread support on top
of one native thread.
Hence, if a JVM's green thread implementation does not preempt nor do time
slicing, then it won't do your "true multitasking" very well. Why? Well,
the only mechanism to pass control from one thread to another is by getting
the running thread to yield. If it doesn't yield, then of course it won't
multitask well.
In a native threads situation very likely the underlying operating system
implements some sort of preemption and/or time slicing mechanism (yes they
are different things). The operating system hence can control which thread
gets the CPU. So you get "true multitasking".
Non-Java processes don't have the problem because "processes" are
heavyweight native threads, essentially. Non-Java threads MAY have the
problem if they are not native threads.
Assuming you are talking about Linux when you talk about G++, yes Linux
implements a time slicing mechanism. I don't think it implements preemption.
>Hmm. Everyone says that's the best thing about native threads. But what about
>"true" multitasking? In my experience, green threads don't do that very well.
>For example, if I have two threads of equal priority, one of which are
>performing some calculations (i.e. is not using I/O stuff and such, which
seems
>to implicitly yield() the thread), the other will hang unless I do explicit
>yields().
>
>Surely that's not the case with native threads, is it? I mean, non-Java
>processes/threads don't have that problem (you don't see g++ hanging the
entire
>system until it's finished compiling, do you?).
