Messages in this thread |  | | Date | Tue, 23 Jul 1996 22:45:14 +1000 | From | Richard Gooch <> | Subject | Re: [Linux-Threads] Re: newly released clone() based pthreads package |
| |
Xavier Leroy writes: > > I haven't tried out your clone based POSIX threads package yet, but I > > noticed in the README there was a comment about not being able > > to share pid's. I was looking in the kernel source ( 2.0.0 ) > > last night, and it seems to me that all you have to do in order > > to share the pid's is set CLONE_PID in the clone flags. > > Have you tried this? > > Actually, no. The problem is that, to avoid busy waiting, a thread must > be able to suspend itself and to wakeup another thread. This is > currently implemented using signals. So, a thread must be able to send > a signal to another thread (and not to the other threads, of course), > and this requires threads to have distinct PIDs. > > Alternatively, a new "kill_thread" system call would be needed to send > a signal to a given thread of a given process. > > > [sharing of all thread invariant task_struct data to reduce overhead > > of context switching] > > That's an interesting idea, and I'd suspect that some kernels with > built-in threads (like Solaris or even Mach) are organized this way. > > 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). > > So, we'll see in practice if context switching time is really a > problem.
It is. For case 2, you can't always expect that all threads will take the same time to process their part of the work. When this happens, some threads can be idle. To fix this you need to divide the work to be done into many smaller sections, and run all those jobs. This is termed "load balancing". The question arises how to run each of these little jobs (remember there are far more jobs than CPUs)? The simple approach is to run each job in it's own thread/process. This has the following disadvantages:
- scheduler (context switching) overhead can become significant
- if the algorithm makes heavy use of memory, cache utilisation is likely to drop as each job accesses different parts of memory, hence performance is decreased
The better approach is to have as many threads as there are CPUs plus one, and launch jobs onto the first available thread. One thread is reserved to do the job launching, and it spends most of realtime waiting for a worker thread to finish. The launcher thread should consume very little CPU resources. Once again, this scheme is sensitive to a slow scheduler.
I have a volume rendering application that doubled in speed when we upgraded an SMP machine from Solaris 2.4 to 2.5! The efficiency of the scheduler is a big issue. Having lightweight kernel threads is an established way of achieving this.
Regards,
Richard....
|  |