Date: Fri, 26 Nov 1999 17:11:10 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <Pine.BSF.4.10.9911261633040.544-100000@current1.whistle.com> In-Reply-To: <383F22E4.31155FC7@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
firstly:
You HAVE to sing this to get the full effect....
-(-(--_
/ ( ( \ DO-RE-MI BEER,by Homer J. Simpson.
| |
| | DOUGH... the stuff...
| __ __) that buys me beer...
| / \/ \ RAY..... the guy that
/\/\ (o )o ) sells me beer...
/c \__/ --. ME...... the guy...
( ) who drinks the beer,
\_ _-------' FAR..... the distance to my beer.
| / \ SO...... I think I'll have a beer.
| | '\_______) LA...... La, la la la la beer
| \_____) TEA..... no thanks,
|_____ | I'm drinking beer...
|______/\/\ That will bring us back to...
/ \ (Looks into an empty glass)
D'OH!
Now that we have that out of the way:
On Fri, 26 Nov 1999, Daniel M. Eischen wrote:
> Julian Elischer wrote:
> >
> > > Why does the UTS need any of this, though? It just needs notification
> > > that the thread blocked and some "thingy" that can be used to resume
> > > or cancel it?
> >
> > When the syscall blocks, the saved information above is to be turned into
> > a full frame. The PC (eip) is added (pointing to where we want it to
> > resume when the IO completes) and the thread is set up looking as though
> > it's waiting on it's IO completion block. The UTS gets (actualy should
> > already know) the KSE-ID.
> >
> > On completion of the IO, the io completion block is updated
> > just as it would have been had the syscall not blocked, and
> > the KSE is hung off the subprocess. When the subprocess is next run,
> > an upcall is made to the UTS, with some ID to let it know which
> > completion block to look at. This is simply the same as is some
> > other thread had released a mutex. The whole KSE in fact need not be hung
> > off the subproc because all that is needed is the single mutex address
> > to report.
>
> So when the IO completion block is updated, how exactly is the
> the thread continued? It _has_ to go back into the kernel in
> order to resume. I don't see the similarity between threads
> blocked in userland (on a mutex) and threads blocked in the
> kernel.
The thread context is entirely in user space.
it is waitomg on a mutex that will tell it that some other thread
(in this cas the kernel) has completed tranfering the data it requested
and has updated the io status block.
it was 'transformed' to this when it was reported blocked by the
first upcall. Since most of the status was alreday present on the (user)
stack, all that was required at that time was it's entry into the
mutex hash table and it's eip to be modified so that when it is run it
thinks it has completed the IO. it will then proceed exactly as though
the IO had been completed synchronously.. i.e. checks the status in the
IO status block and retunrs to it's caller.
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
----
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.
>
> > > How do you resume the thread? Longjmp'ing to the blocked system call
> > > won't work because the kernel doesn't know if it's a new system call
> > > or one that is being resumed.
> >
> > If the userland context of the thread looks just like the context of
> > any other thread, then you just run it.
> > When the thread is reported as blocked, you fiddle the context it left
> > behind to make it look like it's blocked on a mutex on the io completion
> > block. when the syscall completes, the result is the equivalent of
> > releasing that mutex. i.e. the thread continues.
>
> 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.
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.
>
> Dan Eischen
> eischen@vigrid.com
>
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
>
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.9911261633040.544-100000>