Re: [Linux-Threads] Re: newly released clone() based pthreads package
Richard Gooch (rgooch@atnf.csiro.au)
Tue, 23 Jul 1996 22:45:14 +1000
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....