From owner-freebsd-arch Mon Jul 30 15:39:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id A72E537B401 for ; Mon, 30 Jul 2001 15:39:33 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA11541; Mon, 30 Jul 2001 18:38:47 -0400 (EDT) Date: Mon, 30 Jul 2001 18:38:47 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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