> Following this thread off and on since it's inception, and being a Java
> programmer myself, can I offer some observations?
Ahh, a Java programmer, that explains it.
> Thousands of threads in a program is not unreasonable.
Thousands of threads of some kind in a program may or may not be
unreasonable. Thounsands of kernel-scheduled threads is, unless the machine
has thousands of processors.
> If you may want to
> take full advantage of a 128 CPU machine, for example, you need _at_
> _least_ 128 threads.
No, you need 128 threads.
> If your threads spend most of their time blocking,
> you need even more threads, you need to overschedule, to make sure you
> generally have enough threads not blocking to make sure CPUs aren't going
> to waste.
If your kernel-scheduled threads spend most of their time blocking, then
your program is misdesigned. You are wasting resources for no reason.
> Unfortunately, due to vagaries of the system, you will have
> points when most of the threads become runnable at once.
This is only the case when you have a very bad threading architecture. For
example, if you one-to-one map Java thread with LinuxThread, you will have
this problem. The fault is not in Java, and it's not in Linux -- it's in the
broken mapping.
> User level threads are not a full solution- they help, and are a good
> thing, but are not a silver bullet. The basic problem is that there are
> still ways for a process to block that can't be intercepted and "faked" by
> the user level threads- page faulting, for instance. And if a thread
> blocks, all threads that share that process are also blocked. Plus, all
> the problems and difficulties of scheduling are not removed, they're
> simply shoved onto the threading library.
Right. The solution is to have kernel threads and to manage them wisely.
Linux currently has everything you need to do this.
> VolanoMark is a real application, and is really sold. People do really
> write programs like this- except that they're generally for the Enterprise
> market. The question here is if Linux is just a desktop/small server OS,
> or if it's also going be an enterprise OS? This isn't meant to be a snide
> or insulting question- I'd actually _prefer_ Linux to simply be the best
> desktop/small server OS out there. But if Linux is going to play in the
> enterprise market- running the same programs and doing the same jobs
> (albeit slower and cheaper) as that Enterprise 10000 server, it had better
> be ready to deal with applications that spawn thousands of threads.
Again, the fault is in the one-to-one mapping of Java threads (which are
assumed cheap) and kernel threads (which are not). If someone writes a C or
C++ application that uses way more threads than there are processors, that
someone needs to be re-educated.
> You're not going to be able to reeducate the hoards of computer pundits
> and anonymous cowards trumpeting Linux as the one true OS (or disparaging
> it in favor of this other one true OS)- but the kernel developers should
> know the answer.
Eh?
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:26 EST