Re: [Linux-Threads] Re: newly released clone() based pthreads package

Dan McCoy (mccoy@pixar.com)
Tue, 23 Jul 96 10:34 PDT


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