Re: > Re: Linux threads -- as seen in NT Magazine
Richard Gooch (rgooch@atnf.csiro.au)
Tue, 15 Dec 1998 18:35:51 +1100
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/