----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
On Tue, 2 Nov 1999, Glen Newton wrote:
> Which are faster/less overhead/better : green threads or native threads?
Green threads look like one thread to the kernel, so if one of them goes
to sleep in the kernel (blocking on IO) the whole process stops. Switching
between green threads should be cheaper (depending on how much state needs
to be saved I guess).
Native threads would not have to wait for each other to send things down a
socket, but at the same time you likely only have one network interface so
... I'd "go native" to make use of any extra cpus I might have. But if you
don't then you can have an apache process running on the extra cpu.
Are there any benchmarks on this? And for a benchmark to answer your
question you have to specify: faster at doing what.
> Is this correct? "Only an artifact" and "only one memory footprint"? I
> thought linux had 1 process per thread, and are kernal threads. I know
The memory is shared between threads, so yes, only one memory footprint.
Each thread needs its own stack, but I assume that those are all
accessable between threads and therefore included in the memory amuont (or
not, if they all get the same size of stack).
> that Linus sees a thread as a "context of execution" (COE), don't tell me
> that clone() doesn't give you something more heavy weight than Solaris
> threads? Even if Linux has nimble process context switching (which it
This is a kernel issue, and it has been discussed at least once under the
subject "linux threads vs. solaris threads".
Try searching
http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html
or go search dejanews.
One thing someone mentioned is that solaris thread switching is about the
same cost as linux process switching. I have no idea if that is true, but
there was a discussion of modifying a benchmark program to try and find
some numbers.
> does), Solaris threads were literally designed to have thousands of
> thread floating around! More complex, having kernal threads (lwp's)
> and user threads. IMHO Linux threads will not scale this way, but I am
> no expert.
/usr/src/linux-2.2/include/linux/tasks.h (from 2.2.13)
#define NR_TASKS 512
Oops ... I think this limit is gone in 2.3.x but it could be read as a
sign that linux hasn't a history of handling thousands of threads (I'm
sure there are patches for this specific thing though).
One of the arguments against solaris in the discussions mentioned above is
that the thread/process switching is more complex to handle big
multiprocessor systems, making it more expensive for the few-cpu system.
> Is someone out there more knowledgable and fairly "objective" comment
Ha! Well, then I suppose I should cancel this mail right now. :)
Anything written should be read as mere speculation and random quotes from
unknown sources grouped together. (This of course qualifies it as the
basis for an article on ZDNet and similar ... :)
/Urban
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
