Re: newly released clone() based pthreads package

David Woodruff (
Tue, 23 Jul 1996 17:44:31 -0400 (EDT)

> > 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.

This sounds like the way to go ( at least to me ) -- this would also
get rid of the nessessity of using those two user signal handlers ( I believe
I saw this in the README ? ).

> > [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.

There were a couple other responses that seemed to indicate that
it is -- there is obviously some merit to the idea, as other os's
like Solaris are using threads hosted on light weight processes.

If like in case 1-, the program spends lots of time in the i/o system
calls, I think this make it especially important to have fast
context switch time. Right now anyways, libc functions use
locks to protect access to the global structures used in the i/o
( the stream based functions like printf ), and this would make
fast context switch times important for i/o bound threaded programs
in which there is contention for the libc i/o data.

I haven't thought to much about case 2-, I figure it will be a LONG time
before I end up with a multiple process linux box.

 Peeter Joot          TOROLAB(PJOOT)
 IBM Canada           Tie Line 778-3186      Phone 416-448-3186