or some better scheme.
On Tue, 15 Dec 1998, Richard Gooch wrote:
> Paul Barton-Davis writes:
> > >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.
>
> The spinlocks in LinuxThreads are a hybrid user/kernel entity. They
> (IIRC) first spin a few times, reschedule a few times, then they go to
> sleep. In the example cited above, why won't you get the desired
> behaviour with this mechanism?
>
> Process 1 unlocks process 3, then locks waiting for 3 to finish. When
> process 1 yields, process 3 will be run (since process 2 is on the
> other CPU).
>
> > 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 :)
>
> Certainly has for me :-)
>
> Regards,
>
> Richard....
>
> -
> 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/
>
________________
/ David Feuer \
| dfeuer@mbhs.edu |
| feuer@his.com |
\________________/
-
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/