Date: Fri, 26 Nov 1999 23:09:38 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <383F5982.CC9F132C@vigrid.com> References: <Pine.BSF.4.10.9911261633040.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry about the last post; I accidently hit send. Julian Elischer wrote: > You HAVE to sing this to get the full effect.... Thanks! > Each thread has a pernamently assigned IO status block and it's errno > lives there. The contents of the IO status block are updated when the > KSE that was blocked returns. SInce it was blocked it then hangs itself > (or a proxy) off the sub-proc "unblocked" queue. Had it not blocked, > it would simply update the status block and retunr to the userland > which would check the status and return to the caller. > > code path in library for (write); > > set IO status to 'incomplete' > setjmp(mycontext) /* save all the regs in thread context*/ > set saved mycontext->eip to point to 'A' > call kernel > lngjmp (mycontext) > /* notreached */ > > B: > while status == incomplete > wait on mutex in IO status block > A: > check status > return to calling code This seems overly complicated just to perform a system call, but OK. You were talking about putting the trapframe (or most of it) on the user stack, so why not just put the address of the trapframe (stack pointer) in the IO control block. No need for setjmp/longjmp unless the system call blocks. > > when the thread is reported blocked: > the return mycontect->eip is changed from "A" to "B" > code is run to put the thread into whatever > structures the UTS maintains for mutexes. That completes all processing. > It then goes on to schedule another thread. > from the thread's point of view, it has just woken up from waiting > on a mutex. The IO is mysteriously complete. Why mutexes? It just needs to be marked blocked/suspended/whatever. The UTS will only run threads that are in the run state. There is some overhead with mutexes. > > What I don't quite see yet is how you resume a thread at the kernel > > level. You can't just "run the thread" after the IO control block > > was updated indicating that the thread unblocked. You need to resume > > the thread within the kernel. As long as you need a kernel call to > > resume/cancel a blocked thread, why try to hide it behind smoke and > > mirrors ;-) > > No you don't need to go back to the kernel. > All kernel processing has completed. This is what I don't see. When KSEs are woken-up in the kernel, how are they resumed? If you have 10 blocked KSEs hanging off a process, and they all become unblocked before the process runs again, what happens the next time the process runs? KSEs can also hit tsleep more than once before leaving the kernel. If the kernel automatically completes the KSEs, then the kernel is arbitrarily deciding the priority of the threads. There could be runnable threads with higher priority than any of the threads blocked in the kernel. > All your upcall needs is the address of the IO completion block that contains > the mutex to release. All copyin()s and copyout()s have been completed, and the > IO status block has been updated, just as if the call would > have been synchronous. (in fact the code that did it didn't know that it > was not going to go back to the user.) > just before it was going to go back to the user, it checked a bit and > discoverd that instead, it should hang itself (or a small struct holding the > address of the IO completion block) off the subproc. (If the latter the > KSE can actually be freed now). At some stage in the future (maybe immediatly) > an upcall reports to the UTS the addresses of all completed IO status blocks, > and the UTS releases all the mutexes. OK, I think this answers some of my questions. KSEs are automatically completed by the kernel to the point where they would return control to the application. I'm not sure I like that because the UTS can't decide which blocked KSEs are resumed - they are all resumed, possibly stealing time from other higher priority threads. 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?383F5982.CC9F132C>