Nathan Meyers wrote:
> 1) The kernel controls it, or
>
> 2) It's controlled in user space.
>
> Native threads use answer #1, while green threads are the (nearly)
> OS-independent Sun version of answer #2. They have the advantage of
> working, with some porting effort, on OSes that don't support threads
> well in the kernel and/or in system libraries.
IMHO, Native threads use #1 or #2, whatever the OS at hand finds fit to offer,
and green threads are an implementation of #2. That's basically all you can say
- native threads don't necessarily pre-empt, and it is unwise to make
assumptions anyway.
For development, use green threads (cooperative multithreading tends to expose
MT programming errors, like forgetting to yield(), very quickly). For
deployment, see what's best. Native threads may use SMP capabilities better,
and native threads when they're preemptive will probably be better at
controlling CPU-bound threads. For the average Java app/service, where most
work is I/O bound (GUI, network), green threads should be a tad faster because
they are adapted at what Java's needs and its cooperative thread switching is
typically faster (setjmp()/longjmp() call) then preemptive switching (which
will probably invoke a syscall).
Whatever the JVM, you *have* to assume that on the Java level, you'll need to
explicitely implement threads to deal with a cooperative scheduling setup. You
can assume that in a loop, any I/O call will yield (so you don't need to do
stuff in a server accept() loop, for example), but otherwise think about what
your code is doing and try to make it sleep() or yield() as often as is
reasonable.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
