Messages in this thread |  | | | Subject | > Re: Linux threads -- as seen in NT Magazine | | Date | Tue, 15 Dec 1998 00:25:27 -0500 | | From | Paul Barton-Davis <> |
| |
>From: Richard Gooch <rgooch@atnf.csiro.au> >Date: Sun, 13 Dec 1998 08:12:15 +1100 >Subject: Re: Linux threads -- as seen in NT Magazine > >David Feuer writes: >> ***I think it would be _very_ good to make sure that threaded-pipeline >> programs are run in a reasonable way (for example, it would probably not >> be good if pipeline went 1-2-3, but 1 and 3 ended up on the same >> processor).*** > >If you have the processes blocking on each other, then they will be >scheduled on the "right" processor. If the processes don't block then >it shouldn't matter. >If you think the current implementation isn't working, benchmark and >analyse it to show us how.
In the general case, the kernel cannot determine which N threads of a set of M threads (where M > N) are the best to run at a given point in time. "best" here doesn't refer to goodness(), but to user-level application performance. The pipeline David referred to may well be implemented entirely at user-level, using UL spin-locks that are invisible to the kernel. There is therefore no way for the kernel to ensure correct scheduling. All it knows is that a thread called sched_yield(), but has no idea why, or under what circumstances it might want to run again.
All of this stuff is the standard UL vs. Kernel thread argument. Linux doesn't solve it, rightfully so at the moment, but to pretend that the current implementation is even close to "correct" for multithreaded applications is a joke. Fortunately, it just so happens to work for most of the time :)
--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/
|  |