http://groups.google.com/groups?hl=en&lr=&safe=off&th=cdcbca8990d50234,5&rnum=4&ic=1&selm=7oka7r%24v7l%241%40twilight.ee.byu.edu Advanced Groups Search Groups Help Search all groups Search the Web Message 4 from the thread "How many thread can I use with Linux" Message 4 in thread From: Justin Tripp (justin@spam.ee.byu.edu) Subject: Re: How many thread can I use with Linux Newsgroups: comp.os.linux.development, comp.os.linux.development.apps, comp.os.linux.development.system View complete thread (5 articles) Date: 1999/08/08 In comp.os.linux.development.apps Robert Krawitz wrote: : kaz@ashi.FootPrints.net (Kaz Kylheku) writes: :> On Sat, 7 Aug 1999 08:37:49 +0900, Junedong Kim wrote: :> >Hello, I wonder how many thread could run on kernel 2.2 simultaneously :> >In my Linux box, with kernel 2.0x, What kind of threads are you trying to use? If you are using the threads inherent to linux (i.e. LinuxThreads), you really need to use a linux version based on glibc (most 2.0X are not...). If you have glibc and a recent version of linux threads -- then you need to look at what you are doing and trying to accomplish. There are different kind of thread models: kernel threads, user threads, and hybrid threads. These can also be called 1:1, 1:many, many:many or something like that. Anyway, the different thread model determine the characteristics and capabilities of a threaded program. Most portable threads are user threads (e.g. mit pthreads, GNU pth, etc.) User threads run as one process and this process schedules the threads itself. It could be said that these processes run in "user" space. On the other hand, kernel threads are scheduled by the kernel in "kernel" space. This has some draw backs and benefits. User space threads can have their priority controlled. Kernel space the kernel will determine when they will run. User threads are NOT scalable on SMP machines. Kernel threads are scalable on SMP machines. So if you have a Quad Xeon or maybe a 256 processor NCR box, you may want to run kernel threads. If you do not want scalablility or you wish to run separate processes and have threads within those processes, then you can run user threads. :> >I saw /usr/include/loca_lim.h, :> >it said max num od thread in a process 64 and :> >max implementation 1024, The maximums you quote are not exactly what you said. /* The number of threads per process. */ #define _POSIX_THREAD_THREADS_MAX 64 /* This is the value this implementation supports. */ #define PTHREAD_THREADS_MAX 1024 The first number is for POSIX compatibility. So, if you want you program to run on POSIX compatible machines then you should obey it. This is just the maximum that POSIX allows -- LinuxThreads allows up to 1024 and this is fairly hard limit due to the implementation. In fact, you probably cannot run 1024 threads on a linux box (that is 32bit). Since LinuxThreads are kernel threads they are heavy threads/light processes. This means that each one has near the characteristics of a process. Each one has its own memory space. The following comess from the LinuxThreads README: - The stacks for the threads are allocated high in the memory space, below the stack of the initial process, and spaced 2M apart. Stacks are allocated with the "grow on demand" flag, so they don't use much virtual space initially (4k, currently), but can grow up to 2M if needed. Reserving such a large address space for each thread means that, on a 32-bit architecture, no more than about 1000 threads can coexist (assuming a 2Gb address space for user processes), but this is reasonable, since each thread uses up one entry in the kernel's process table, which is usually limited to 512 processes. Another potential problem of the "grow on demand" scheme is that nothing prevents the user from mmap'ing something in the 2M address window reserved for a thread stack, possibly causing later extensions of that stack to fail. Mapping at fixed addresses should be avoided when using this library. Using LinuxThreads then you are limited to ~1000 threads because every thread has its own memory space and your memory space is limited to 2G. If you have an Alpha or something, then you maybe able to avoid this problem with a 64bit memory space. This would allow for atleast millions, even if you upped the individual memory space to 4 or 16Megs. :> >I think it so hard! did I refer right info? :> >if so, How can I increase the max num of implemented thread :> >pleaz, tell me real fact about that. It is kind of odd that you think this is so hard. I have played around with the LinuxThreads and found them very useful. Using a Dual PIII 450 I can run 1019 threads -- but you see this is like running 1019 processes. Since the kernel schedules them, they do appear in top or the run queue -- so it is like 1019 load lines. Needless to say that approach makes the machine most unusefull for other processes. Running 1019 threads was slightly slower than running 2 threads ... but I was testing with a PI calculation prgram. It had no communication between threads. Any application where the threads needed to pass information would have slowed down significantly as more threads were added. Parallel applications that have no communication are generally regarded as trivial since they probably do not do much useful. I was able to get the kernel and linuxThreads to schedule 200 of my threads to run concurrently. This result in a system load of 200 (and general unresponsiveness.) If your machine can deal with huge loads like that feel free, but if you have just a reasonable machine you may wish to take the below advice and reconsider what you are doing. :> You should be looking to find out how to minimize your application's :> use of threads, rather than how to increase the system limits. If :> you need to create as many, or more threads, as a regular Linux :> kernel setup allows you, you are doing something wrong. Maybe you :> don't have a lot of experience designing threaded applications, so :> you think that every object (or client, or cell in a matrix, or what :> have you) needs its own thread. It seems that every programmer who :> learns about threads wants to do things this way. A few threads are :> better than just one, so a huge number of threads must awesome! : It's possible that this is the case, but the original poster may have : valid reasons for wanting more threads (or processes, or what have you). : -- : Robert Krawitz http://www.tiac.net/users/rlk/ Just in case you don't think anything I have said is useful, the following links might be useful for related info: LinuxThreads http://pauillac.inria.fr/~xleroy/linuxthreads/ MIT Pthreads http://www.humanfactor.com/pthreads/mit-pthreads.html GNU Pth http://www.gnu.org/software/pth/ -- ------------------------------------------------------------------------ Justin Leonard Tripp justin@spam.ee.byu.edu Configurable Computing Laboratory Research Assistant CB 461 x8-7206 Electrical and Computer Engineering Department Brigham Young University Google Web Directory - Cool Jobs - Advertise with Us - Add Google to Your Site - Google in Your Language - All About Google ¨Ï2001 Google