Messages in this thread |  | | Date | Tue, 23 Jul 96 10:34 PDT | From | (Dan McCoy) | Subject | Re: [Linux-Threads] Re: newly released clone() based pthreads package |
| |
From: Xavier Leroy <Xavier.Leroy@inria.fr> >However, it could be that the extra overhead of context switching is >tolerable in most applications. In my experience, threads are mostly >used to 1- do input/output in an overlapped way, and 2- >heavy-duty computation on multiprocessors. In case 1-, the program >spends lots of time in i/o system calls anyway, and for 2-, the goal >is to have one thread per processor and as few context switches as >possible (e.g. by tieing threads to processors, or at least giving >affinities between a thread and a processor).
In the heavy-duty computation case on multiprocessors, you are right in the ideal case. In the less than ideal case (like the application I am working on under Solaris right now) there is a significant amount on locking of shared data structures involved.
If the multiple threads were completely free-running, kernel scheduling would be just fine. When the amount of mutex contention gets to a certain point, you end up with threads that have to block. Every time you have to block on a mutex you are doing a context switch.
One way to lighten this load is using the N to M model that Solaris uses. I use a few more user threads than kernel threads (LWP in Solaris terminology). Then, when a thread blocks on a mutex because another thread has it locked already, the user mode thread scheduler can usually find another thread capable of getting some work done without resorting to a system call.
Dan McCoy Pixar mccoy@pixar.com
|  |