From owner-freebsd-arch Mon Nov 29 19:48:53 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 33ECB1570D for ; Mon, 29 Nov 1999 19:48:00 -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 EAA27460 for ; Tue, 30 Nov 1999 04:47:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA68243 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 04:47:58 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0F40715717 for ; Mon, 29 Nov 1999 19:47:43 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt1.pcnet.net [206.105.29.75]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id WAA03497; Mon, 29 Nov 1999 22:47:33 -0500 (EST) Message-ID: <38434896.84693F95@vigrid.com> Date: Mon, 29 Nov 1999 22:46:30 -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: Matthew Dillon , Nate Williams , Julian Elischer , Jason Evans , 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 Chuck Robey wrote: > > No context here, because I want to ask another question regarding the > proposals, but it's context is too stale to repeat. I've finished reading > the SA paper, and one question bothers me. > > 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. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message