[lkml]   [1998]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject> Re: Linux threads -- as seen in NT Magazine
>From: Richard Gooch <>
>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

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 :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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