From owner-freebsd-arch Tue Nov 30 4: 4:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4B50D152AC for ; Tue, 30 Nov 1999 04:04:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA04212 for ; Tue, 30 Nov 1999 13:03:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA69897 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 13:03:56 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9B3131573E for ; Tue, 30 Nov 1999 04:03:36 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt46.pcnet.net [206.105.29.120]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA23878; Tue, 30 Nov 1999 07:03:34 -0500 (EST) Message-ID: <3843BCE0.4BB7001C@vigrid.com> Date: Tue, 30 Nov 1999 07:02:40 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Robey Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [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