Date: Tue, 30 Nov 1999 07:02:40 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Chuck Robey <chuckr@picnic.mat.net> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <3843BCE0.4BB7001C@vigrid.com> References: <Pine.BSF.4.10.9911292352060.20163-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[CC list trimmed] 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? The problem is not specific to SA; you can page fault in a critical region (fiddling with one of the user-level scheduling queues, for instance) regardless of whether you are using scheduler activations. The UTS will be doing pretty much the same things every time, so it is hoped that the pages will stay resident and not get swapped out often. Dan Eischen eischen@vigrid.com 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?3843BCE0.4BB7001C>