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

Regards,

- Xavier Leroy


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