>>>>> "Juergen" == Juergen Kreileder <[EMAIL PROTECTED]> writes:
>>>>> "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
Matt> In either case we need to get Linux native threads to scale
Matt> much better than they do now. This might mean convincing the
Matt> kernel developers that scaling up to thousands of threads is
Matt> important --
> I still haven't seen one good argument for using thousands of threads
> except for working around Java's _current_ IO limitations and doing
> better on benchmarks which test work-arounds for these IO limitations.
Matt> does anyone have a reading on what the kernel folks think
Matt> about the current situation? In the past I believe they
Matt> didn't think this was an important problem to solve.
> The basic problem seems to be a different understanding of threads.
> Java programmers tend to see threads as an ordinary design concept
> while most other people see threads as a concept to improve
> performance.
I think the problem is that Sun has overloaded the word "Thread" with
a related but inherently non-identical concept and then compounded the
braino by suggesting that implementators continue the confusion. But
see below...
> Java developers tend to use too many threads and wonder when
> performance degrades. Linux's current thread model is designed to
> give best performance with a handful of active threads (and a
> two-level scheduler would bring a slight performance penalty for this
> case).
Agreed - beginners *do* tend to use too many threads, not realizing
that there is a penalty implied by any implementation of the Java
semantics. Of course, these same programmers are also usually
surprised when their threads deadlock or corrupt each other's data.
Mostly, this is just the usual misunderstanding about how complex a
given feature is - how many programmers have spent days hand-tuning a
comparison function while using a n^2 sort algorithm? This will
always be a problem, but it is primarily one of education and
documentation. For instance, "don't use a thread unless you expect
to actually execute the main body of the runnable code many times."
The default VM implementation should be tuned to the most common
"good" use, whatever that turns out to be. I'm a little upset about
the -client vs -server bifurcation: I'd rather see application-tunable
parameters since my app is neither client nor server.
A two-level scheduler would solve a different problem, though: "Java
developers who use many threads wonder why the application/VM/computer
works great at N but dies a horrible flaming death at N+1." My
observation is that the solutions which are proposed as ways to avoid
"too many threads" syndrome are invariably equivalent to custom
schedulers.
We could all just use a library with a general-purpose scheduler
(doesn't Doug Lea's Concurrent package have one?), but it seems to me
that the VM could do a much better job at it (preemption, much finer
timeslicing) and the result would be to treat a potentially good
language abstraction as a second class citizen.
On the third hand is the issue that java-runtime-space schedulers
cannot timeslice - green and native threads can make progress where a
written-in-java scheduler depends on good behavior of the code being
scheduled. This is only *not* an issue when the scheduled bits always
run in short, predictable times and never block or when the semantics
of the application imply that only one thing can actually be worked on
at once.
cheers,
-mik
--
Michael Thome ([EMAIL PROTECTED])
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
