Date: Tue, 04 Jul 2006 12:41:51 -0700 From: Julian Elischer <julian@elischer.org> To: David Xu <davidxu@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, threads@freebsd.org, Robert Watson <rwatson@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: Strawman proposal: making libthr default thread implementation? Message-ID: <44AAC47F.2040508@elischer.org> In-Reply-To: <200607042204.52572.davidxu@freebsd.org> References: <20060703101554.Q26325@fledge.watson.org> <200607040612.23493.davidxu@freebsd.org> <Pine.GSO.4.64.0607040904310.11608@sea.ntplx.net> <200607042204.52572.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: >On Tuesday 04 July 2006 21:08, Daniel Eischen wrote: > > > >>The question was what does libthr lack. The answer is priority >>inheritence & protect mutexes, and also SCHED_FIFO, SCHED_RR, and >>(in the future) SCHED_SPORADIC scheduling. That is what I stated >>earlier in this thread. >> >> > >As other people said, we need performance, these features, as you >said, in the future, but I don't think it is more important than performance >problem. you have to answer people what they should do when they bought >two cpus but works like they only have one, as the major author of libpthread, >in the past, you decided to keep silent, ignoring such requirement. >also, the signal queue may not work reliably with libpthread, this >nightmare appears again. > > As much as it pains me to say it, we could do with looking at using the simpler mode of 1:1 as the default. M:N does work but it turns out that many of the promissed advantages turn out to be phantoms due to the complexities of actually implementing it. The main problem that occurs again and again is that the kernel has no history of how a particular thread ran, which is important for our scheduer, and that there are other places where it would be advantageous for the kernel to have visibility into the whole pool of threads. There is actually an answer for the 1st problem that I have played with but there continue to be complexities introduced that make it difficult. For example, keeping statistics alligned woth threads and reporting them for the correct thread is exteremely difficult. THIS MUST NOT be confused with the complexities introduced by trying to make threads run fairly. Some of the percieved advantages of going to 1:1 are in fact only achievable if we abandon fair scheduling, which is a completely orthogonal issue. The complexity that introduce the extra locking in the schedular that Kip refers to, is the attempt to do fair scheduling and is independent of 1:1 or M:N. If someone could work out a way that fair scheduling could be achieved without the extra locking then that would be valid for both M:N and 1:1 THREADING, and would solve Kip's problem. > > > > > >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AAC47F.2040508>