Hi, Tobias Frech wrote: > There is a interesting thread on linux threads here: > http://www.jboss.org/forums/thread.jsp?forum=52&thread=2273
Yes, and it kind of exposes the confusion on this. A few years back I did a lot of Linux kernel hacking, so I guess I know a little about this. It is correct that all the different java threads share the same memory image. They also share all open file descriptors. But I am not sure if this can be called "lightweight" threads: In the kernel, each of these threads are scheduled independently, and the recalculation of the dynamic priority happens independently for each thread. Conpare this to lightweight threads that are usually scheduled in a simple round-robin way, under the control of the dynamic priority of the process. Changing the kernel to allow more processes is simple, as you only have to change a constant and recompile the kernel. If you change this, and have a lot of threads sharing the same memory image (like in the JBoss case), you may also have to lower the constant defining the thread stack size in linuxthreads (part of glibc), as each thread needs its own stack in the shared memory image, and you do not have room for a lot of stacks if each stack occupies 2 MB as default. JBoss seems to run fine with a 256 KB stack size. But with a lot of threads, you will see another problem: Threads are processes in Linux, and their dynamic priority (goodness) has to be recalculated in the kernel. The algorithm Linux is using for this is slow, but good. Good dynamic priority recalculation means that the overall system feels very responsive even under load, but the recalculation also eats processor cycles. To get around that problem, IBM has developed a patch to the Linux scheduler that enables faster (but not quite as good) dynamic priority recalculation. This patch was not accepted into the kernel, as it makes the system feel less responsive under normal conditions. But even with all this done, it is just a matter of starting enough threads before you start seeing the same problems again. And you should also see similar problems on other systems if you start enough threads. Anyway, (non-realtime) threads are IMHO nothing but a programmer's convenience, and should not be used if they can be easily avoided. In particular, on native-threads Java VMs, starting and stopping threads is very slow compared to other operations because it involves calls to the operating system. Best Regards, Ole Husgaard. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
