Date: Mon, 7 Dec 1998 22:16:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP Message-ID: <199812072216.PAA16574@usr06.primenet.com> In-Reply-To: <199812070443.MAA17869@spinner.netplex.com.au> from "Peter Wemm" at Dec 7, 98 12:43:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Perhaps I've missed something obvious But: it seems to me that a process > > > that uses multiple threads doesn't spread them over more processors? > > > I tried on a dual PII, running fbsd 3.0, and a program that simply did > > > a few pthread_create() calls. > > > > Correct. No-one with enough skill to do the work necessary to get thread > > migration supported has had the time... > > It's not so much a question of skill, it's just a moderately big job with a > fairly large kernel vm/pmap layer impact and nobody (so far) has had the > time to do it. And then there's the issue of connecting the kernel > support up to a thread library to implement the posix interfaces to it. One reason I haven't piped up on this (I *do* have the scheduler changes for CPU affinity working, actually) is that apart from that, there's still the issue of the per thread stack. I am not very satisfied nor happy with the allocation of stack in the same VM space in each thread (for reasons of stack autogrowth), and I would want to address that before anything else. Stack issues pushed aside (i.e., ignored), I think there is a serious bug in the current implementation of the sfork call, which one can see as a vfork bug when trying to send a reply with a message file using the vacation program (the file is prematurely closed instead of using the pipefd, and you end up getting empty message bodies as a result). Avoiding vfork is possible, if one is willing to lose a (to my mind) critical part of the error reporting; but the point is that there is cruft in there. Finally, apart from affinity, kernel threads are relatively useless as an implementation without cooperative user space scheduling. The only OS which I am aware of having addressed these isses at this point is Solaris. So I agree that it's a big job, but there *is* a certain amount of skill required, as well, especially if you want to meet the spirit of the POSIX standard, and not just the letter. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812072216.PAA16574>