lkml.org 
[lkml]   [1996]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.018 / U:1.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site