-evt
Eric van Tassell
Texel Software, Inc. - System Software Engineering for Windows/NT
277 Cochran Hill Rd. Voice : 603-487-5006
New Boston, NH 03070 USA Fax : 603-487-5166
email : evt@texelsoft.com
http://www.texelsoft.com
> -----Original Message-----
> From: owner-linux-kernel@vger.rutgers.edu
> [mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of Paul
> Barton-Davis
> Sent: Tuesday, December 08, 1998 3:54 PM
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: Linux threads -- as seen in NT Magazine
>
>
> >The December issue of _Windows NT Magazine_ features an article:
> >"NT vs. Unix." The article includes a sidebar "Linux and
> >the Enterprise," which begins:
> >
> > Whereas Windows NT and all leading commercial operating systems
> > (OSs) implement kernel-mode threads, Linux does not. The Linux
> > scheduler does not divide CPU time among threads but among
> > processes. Each process in Linux has an implied execution state
> > that, on other UNIX variants, is the equivalent of a thread.
> > Thus a Linux process is similar to a process on other UNIX
> > versions that has exactly one thread and cannot create more.
> >
> > Linux's omission of kernel-mode threads seriously affects
> > application developers' ability to write software that takes
> > maximum advantage of a CPU. Linux application developers must
> > use user-mode threads that the system implements in user space.
> > User-mode threads are also called <i>cooperatively scheduled
> > threads</i> because kernel schedulers do not know that the threads
> > exist, and therefore the schedulers do not divide CPU time among
> > the threads. . .
>
> 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/
>
-
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/