>>>>> "Stefaan" == Stefaan A Eeckels <[EMAIL PROTECTED]> writes:
> On 09-Jun-2000 Michael Thome wrote:
>> I think the best answer is to do the second tier threading in userspace
>> (best would be in glibc). The kernel folks have some good points
>> about doing it the kernel but seem to have a mental block as to why
>> you'd *ever* want hundreds of threads in a single app.
> I'm not one of the kernel folk, but can you give me an example of
> an application that would be impossible without hundreds of threads?
> Or even one that would significantly benefit from hundreds of threads?
I'm concerned about two related issues which are somewhat different
from what others have proposed [I spent this morning reading all the
email I ignored while at JavaOne - I *have* read the other responses to
your question, so I will not bother to restate the whole threads+IO
discussion].
1. Java proposes Thread as a general-purpose language abstraction,
complete with syntactic support for synchronization. Any Java VM
implementation which significantly limits the ability to use this
abstraction violates the spirit of the language design (if not the
letter, given the amount of handwaving in the JLS). Yah - I know, I
know... but would you accept a VM which seriously restricted stack
depth? Too much inheritence? Too many objects?
2. Use of Java Threads as a language abstraction allows scalability
without code modification *when the VM implementation does not impose
unfortunate limits on such use*. Given (1) above and the whole "write
once, run anywhere", it seems completely bogus that one should have to
have completely different implementation strategies for incremental
changes in problem size: language facilities should scale (and
degrade) gracefully - not suddenly crash when you hit an unknowable
(to the runtime) arbitrary limit.
I'd almost rather not have Threads at all if I cannot depend on them -
what's the point?
For instance, the application which I spend my days hacking on is
essentially a moderately-sized (100s to 1000s of nodes), peer to peer,
distributed (10s to 100s) agent system. Each node's infrastructure is
naturally implemented with a handful of threads. There may be any
number, though usually in the 10-20 range, of long-lived servlet- or
plugin-like software components added to each node... While the most
natural way to handle the plugins is with a Thread for each, we've
already gone to doing our own scheduler for most of them. Now, in a
deployed system, you'd probably have hundreds of machines, each with
one node, each node with maybe 15 plugins. That's approx 20 threads
per VM using our current system. On the other hand, some sites will
be happier buying big SMP machines and running many nodes on one piece
of hardware (uh oh - 10 nodes in one vm is already into the 100s of
threads). For debugging, configuration, regression and QA purposes,
it is often useful to start up a whole network on one computer (or one
VM!) - my machine is perfectly capable of doing this with green
threads, but using native threads (<=kernel-2.2) is a complete no-go
in this situation.
Now, the kernel-2.3 situation is much better, but there is still the
tension inherent in coupling any language abstraction to a relatively
heavy and constrained OS facility: On a single-cpu machine, userspace
threads really ought to be faster since they'll require less data
structure and the (Java) VM can know more about them than any general
purpose facility could. This certainly has been the case in the past
- I'm not sure what the situation is now, but it seems unlikely to
have changed that dramatically.
Cheers,
-Michael Thome
[EMAIL PROTECTED]
--
Michael Thome ([EMAIL PROTECTED])
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
