Date: Mon, 29 Nov 1999 21:34:40 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Chuck Robey <chuckr@picnic.mat.net> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.BSF.4.20.9911292120220.12455-100000@home.elischer.org> In-Reply-To: <Pine.BSF.4.10.9911292352060.20163-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Nov 1999, Chuck Robey wrote: > > Scenario: UTS on processor 1 is stopped due to a page fault, while it's in > a critical section. UTS on processor 2 is entering a critical section, a > spin lock which will end up in conflict with the processor 1 UTS, when it > gets the upcall, telling it that processor 1 has a suspended UTS, so that > this second UTS is pretty much dead in the water. > > If it's possible for a UTS to get a page fault (or any other unpredictable > swap-out) during a critical section may be a really bad idea. If it's > possible for threaded process to run on multiple processors in time slots > that *aren't* synchronous, then deadlocks would be a problem there too. > > The difference I see between UTS threads, as against all other threads, is > that all other threads implicitly depend on the UTS, so the UTS can't hang > without serious performance impacts. Isn't this a problem for SA > implementations? My take on this is as follows: The UTS has some sort of structure that is private to itself. it also has a descriptor for each thread, and each thread has a stack on which there is some saved context. The kernel needs to know that when the UTS is blocking it should NOT perform an upcall. The result of this is that yes, the UTS actually blocks. However this should only happen at startup because the UTS will be hot code and data. The kernle knows it's the UTS because it knows where the UTS's stack is and cna check whether the blocking thread is on that stack. Other time s that the UTS might block in a pagefault are when loading context from the incoming thread's stack (it may have been paged out.) and when reading the structure describing that thread. In the first case, the UTS is about to relinquish control of the processor to the incomng thread, so we can move it's stack pointer to a location within the new stack already. This nesures that it will not be recognised as being the UTS and some other thread will be given the oportunity to run while the page is being brought in. The second is a bit more difficult, because the UTS may need to read this structure while doing more mundane tasks, (e,g figuring out who to run). However this structure is quite a bit smaller. it is possible that the page on which it sits will alway be in core as somewhere else on it is a thread that get's called more often. Still we need to keep this page resident. It is possible that we may be able to do some mmapp or sysvSHM trick to keep this small region in core. Failing this we may just need to block. I'm not sure that a goal of teh thread system is to have the programs NEVER EVER EVER block. What iof the whole program is swapped out at a busy time? What we can do however is make it pretty dammed unlikely, by keeping these structures small and in hot pages. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.9911292120220.12455-100000>