Date: Tue, 30 Nov 1999 01:10:07 -0500 (EST) From: Chuck Robey <chuckr@picnic.mat.net> To: Julian Elischer <julian@whistle.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.BSF.4.10.9911300059080.20163-100000@picnic.mat.net> In-Reply-To: <Pine.BSF.4.20.9911292120220.12455-100000@home.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Nov 1999, Julian Elischer wrote: > > 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. If one of those strategies is used to ensure that the UTS never swaps, then will we also be sure that, when a threaded process is running on two different processors, that the timing will be synchronous (both processors threaded process timeslots exactly coincide) so that one UTS can never block waiting for a non-running UTS to come back? The argument I'd heard ealier was that we wanted to have threads spread across as many processors as possible, but this seems to mean that they must happen at the same time (or else not hold locks when being switched out). I see that there are two possibilities for one UTS to be sleeping, when another wants to utilize shared state: (1) a UTS takes a page fault, or (2), a UTS takes a process context switch. You've explained (1) fine for me (assuming one of the forced-residency strategies is followed). I think (2) may end up being a requirement. Are there any other cases where the execution of UTSs get out of sync? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- 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.10.9911300059080.20163-100000>