From owner-freebsd-arch Mon Nov 29 21: 3:29 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 D63FD14C17 for ; Mon, 29 Nov 1999 21:03:24 -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 GAA28111 for ; Tue, 30 Nov 1999 06:03:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA68544 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 06:03:23 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 7BAD415768 for ; Mon, 29 Nov 1999 21:02:57 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id AAA38443; Tue, 30 Nov 1999 00:01:40 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Tue, 30 Nov 1999 00:01:40 -0500 (EST) From: Chuck Robey To: "Daniel M. Eischen" Cc: Matthew Dillon , Nate Williams , Julian Elischer , Jason Evans , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <38434896.84693F95@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Nov 1999, Daniel M. Eischen wrote: > > It looks like the kernel is making upcalls into the UTS. It further looks > > like there could be multiple copies of the UTS active, either because of > > multiple processors, unsynchronized process swaps of processes with UTS's > > that are active, and upcalls coming in before a previous upcall can clear > > the UTS. I did see that the UTS is required under SA to be re-entrant > > (obviously) but I didn't see any synchronization requirements on the UTS > > specified, and it does look like it would need some global state that > > would need protection. > > The same rules apply to upcalls to the UTS as other threads. Critical > regions must be protected with spinlocks or something similar. If the > UTS, or any other thread, is preempted because the respective subprocess > consumed its quantum, then at the next opportunity on another subprocess, > an upcall is made notifying the UTS of the preemption. The UTS will > check the program counter of the preempted thread (or flag set in > the thread structure) to see if it was in a critical region. If it > was, the UTS will resume it to the point that it leaves the critical > region. > > We may want to limit the time spent spinning and make an explicit check > for preemption, so that the entire subprocess quantum isn't consumed > waiting for the next subprocess to run. 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? ---------------------------------------------------------------------------- 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