Date: Sat, 24 May 2003 11:43:05 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) Message-ID: <Pine.GSO.4.10.10305241130380.295-100000@pcnet1.pcnet.com> In-Reply-To: <3ECF4149.EDCDD1B6@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 May 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > On Fri, 23 May 2003, Terry Lambert wrote: > > > I'm rereading it, but I don't see that interpretation. > > > > > > I guess if both you and Julian both called me on it, I must > > > have misexpressed myself, but I currently don't understand > > > how. 8-|. > > > > I think it was the part about "a single CPU system with > > PTHREAD_SCOPE_PROCESS (the default) can still get itself > > blocked in the kernel by a single blocking call" without > > mentioning that it won't block other scope process > > threads from being run. > > OK... this I don't get. If the scope is process, and you > are implementing M:N, and N == 1, my understanding of the > code is that it will block exactly the same as libc_r. If > it won't (and I'm prepared to believe this), then I'd like > to know "why not?"; it should be that there is a single > scheduling object, no? It will not behave the same as libc_r. When a thread blocks in the kernel, the kernel issues an upcall to the library (on the same KSE) and the library chooses another thread and runs it. And so on, and so on, ... When threads unblock in the kernel, upcalls are also made to notify the library that those threads can be resumed. Unlike libc_r, just because a thread blocks in the kernel doesn't mean that the library won't be able to run other threads. This is the KSE system's raison d'etre. I was pretty sure you knew how all this worked... It makes me think we're talking about different things. kse(2) has some good stuff in it. > Reading the code, I don't get that there will be the ability > to do multiple returns. Is it that a KSEG is intended to > represent a quantum? If so, I've just had an epiphany as to No, the KSE has the quantum. The KSEG has the _kernel_ priority. > why you would want KSEG's at all in the first place (I've > never agreed with Julian on KSEG's, since the earliest days, > and I've only reluctantly accepted their necessity as an > artifact of scheduling priority differences for a strictest > compliance with POSIX mandated semantics -- hence my defense > of them to Jeff when he wanted to change the kernel code to > make them semi-impossible). I didn't really see the need for them either, but it is a way to have a thread group with multiple KSEs and the same kernel priority... -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10305241130380.295-100000>