Date: Tue, 30 Nov 1999 00:01:40 -0500 (EST) From: Chuck Robey <chuckr@picnic.mat.net> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Nate Williams <nate@mt.sri.com>, Julian Elischer <julian@whistle.com>, Jason Evans <jasone@canonware.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.BSF.4.10.9911292352060.20163-100000@picnic.mat.net> In-Reply-To: <38434896.84693F95@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911292352060.20163-100000>