Well, lets get a few things clear.
Linux does implement kernel threads via the clone(2) interface. This
allows lightweight creation of a new execution context, and is
actually much more flexible than either NT or Solaris' kernel thread
creation interface, since userspace can dictate exactly which parts of
the parent execution context are shared. Its very fast, and very
usable, as the POSIX-conformant Linuxpthreads library demonstrates.
Linux does *NOT* implement kernel threads in the sense that its
scheduler equates a "task" (a traditional Unix process) with a
"thread". There is no support in any current Linus-approved kernels
for the notion of a process ("task") that is implemented as a set of
kernel threads.
Therefore, kernel scheduling *is* indeed blind to the idea of a
multithreaded application, and operates on the assumption (which is
actually OK much of the time) that scheduling every kernel thread
independently is the thing to do.
However, its far from always the right thing to do. The current
scheduling model cannot offer proper support to applications that want
to explicitly take advantage of multiprocessor hardware, because it
has no idea that task N and task M actually "belong" to the same
application.
As I've previously mentioned here, I've done some work on changing
this, albeit as part of a more ambitious project to implement
dynamically loadable schedulers. I often run a kernel on my machine
that *does* consider kernel threads to belong to a "group", and offers
them the chance to schedule themselves as they see fit. I have had no
enthusiastic feedback from anyone on the list, and right now, I'm busy
with another fairly ambitious Linux project, so its on the backburner
for now, but once 2.2 comes out, and stuff like this might get more
attention, I'll focus on it again.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/