Date: Mon, 30 Jul 2001 18:38:47 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. Message-ID: <Pine.SUN.3.91.1010730182804.2337A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0107301531110.30207-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Jul 2001, Julian Elischer wrote:
> On Mon, 30 Jul 2001, Daniel Eischen wrote:
> > If KSEs may get notifications for threads running in other KSEs,
> > it means that there will have to be some inter-KSE locking of
> > blocked and running thread queues. And each KSE has it's own
> > mailbox, so it might force KSEs to fiddle with mailboxes they
> > don't own.
>
> no it would never have to fiddle with a mailbox that it didn't own,
> but it might find a thread on its "completed" list that it should
> put on the other run queue. If I don't do that then there will be times
> when I could run a thread but instead will sit idle.
> It is of course easy to do.. (comment out some code :-)
Blocked threads will be put in a per-KSE queue of their own.
Having a different KSE handle the unblocking of a thread would
probably require that the thread be removed from the other
KSEs blocked queue as well as insertion into its run queue.
We could probably use the same per-KSE lock to protect both
run and blocked (and any other) queues though.
> In the first version it will always come back on the same KSE because
> there is a 1:1 relationship between threads and KSEs.
>
> I'm rewriting this stuff at the moment. I 'll make sure it can be done
> either way (allow or not allow a thread to change KSEs while in the
> kernel.)
>
> So, did the rest of what I wrote make sense?
For the most part, yes, though you did write:
> I have not coded the userland boundary crossing stuff yet,
> so at this stage there can only be as many threads as there are KSEs
> and the mapping is permanent. syscalls return directly instead
^Blocking ?
> of producing an upcall to the UTS.
I assume syscalls that don't block will always return directly
to the UTS (unless other UTS notifications are needed).
--
Dan Eischen
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.SUN.3.91.1010730182804.2337A-100000>