Date: Sat, 27 Nov 1999 01:04:11 -0800 From: Jake Burkholder <jburkhol@home.com> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <19991127090411.64B121FDA@io.yi.org> In-Reply-To: Your message of "Fri, 26 Nov 1999 21:34:03 PST." <Pine.BSF.4.10.9911262111220.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> what happens now? > before they are unblocked they are sitting in the system's sleep queues. > When they are unblocked they are transfered to the 'unblocked' queue on > the subprocess, and the subproocess is scheduled onto the run queue for > it's processor. I think that maybe what Daniel is getting at, and what is in the scheduler activations paper, is that when a thread unblocks in the kernel it is _not_ automatically scheduled by the kernel. There is another scheduler activation, notifying the UTS of the event. If there is a higher priority thread in userland, ready to run, the just unblocked thread will remain blocked in the kernel until it is the highest priority thread. The UTS then makes another kernel call, which resumes the thread where it left off when it unblocked from the original system call; it may have more to do, and as Daniel said, hit tsleep again. Allowing it to continue right up to bridge to userland uses up resources that the UTS might rather use on a higher priority thread. > That's Matt's argument. > > > If we had a thread that was super High priority, we should have assigned > it a subproc (scheduling class) that was high priority. Then it wouldn't > be competing with the others. Having a sub-proc designated as higher priority means that the proc would need to know about that, and be sure that when a sub-proc unblocked, higher priority sub-procs were scheduled first. The kernel then has to know alot about priorities, which I think is something Daniel would like to avoid. Also, is it not the case that when a process is making a system call it is not pre-emptable? So when a thread unblocks in the kernel, but there is a higher priority thread in userland, the UTS cannot pre-empt the thread; it must allow it to continue what its doing in the kernel and return to user-land before the higher priority thread can run (on this kse). Jake 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?19991127090411.64B121FDA>