Date: Mon, 29 Nov 1999 22:46:30 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Chuck Robey <chuckr@picnic.mat.net> 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: <38434896.84693F95@vigrid.com> References: <Pine.BSF.4.10.9911292101170.20163-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38434896.84693F95>