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?
You could also argue, that this is an attempt to move java closer
to being a concurrent object oriented programming language. Add serialization
and you get a distributed concurrent object oriented programming language.
Strange enough, most people don't see it this way and argue against
using lots of threads. However, for many cases, threading greatly simplifies
design and programming, especially for event-driven programming (agents
and servlets are nice axamples of such constructs).
I'd almost rather not have Threads at all if I cannot depend on them -Same here... I am hacking an icm-based agent framework. In order to get a real agent from an object, you definetely need a sizable thread pool for message/event dispatching and message handler code execution (an active object brings us closer to building an agent) and one thread pear agent for managing i/o (at least input). Add mobile agent spawning, where security wise you need to isolate the agent into a thread with a special security model and you get the point.
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.
The problem is that green threads can't do the work on their own, since
they can't do much about computationally intensive constructs (or dos attacks,
where a misbehaved thread can kill the rest), and native threads can't
do it at all without select.
I would like to avoid the overhead of using a thread pool whenever
I want to just use a different thread of computation, but the current situation
doesn't allow us to do so.
In short, a hybrid-thread model is what is needed. i/o threads could
be scheduled as lightweight (green) threads, while the real work of code
execution would be done by normal, native - heavyweight threads.
Of cource, we could alleviate the pain by just having select...
Having select could improve the situation, as the i/o threads can be
muxed into a pool - and the vm could easily scale to some thousands of
agents without killing the system. But you still get the overhead of thread
pooling and scheduling...
-- dimitris mailto:[EMAIL PROTECTED]
