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