From owner-freebsd-arch Sat Nov 27 20:38:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A4B9014DD8 for ; Sat, 27 Nov 1999 20:38:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA16685 for ; Sun, 28 Nov 1999 05:38:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA56205 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 05:38:51 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 4876114DD8 for ; Sat, 27 Nov 1999 20:38:44 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt104.pcnet.net [206.105.29.178]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id XAA16392; Sat, 27 Nov 1999 23:38:45 -0500 (EST) Message-ID: <3840B1EC.4614AAF0@vigrid.com> Date: Sat, 27 Nov 1999 23:39:08 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > > I've put a diagram up on my web page that tries to incorporate > > some of these ideas. I haven't included the queue-ing, because > > that seems basically agreed upon. > [...] > > I'm just going from what Daniel said about libc_r having > > to get the time of day and set the interval timer in > > order to do a context switch, which can probably be > > done in one system call. Either the context can be > > saved in userland, in which case the scheduler returns > > normally, and does a longjmp or the equivalent, > > or the thread could be resumed as part of the > > system call. > > > > I don't know what Danthiks but this has alot more involvement or the > kernel and boundary crossing than I was envisionning. I think it's basically right. If you saw the diagram at different stages, it would be easier to see. o A thread blocks in kernel, the KSE is saved, a new KSE is allocated, and an upcall is made to the scheduler with a unique KSE ID provided to identify the now blocked thread. o Scheduler receives notification of a thread blocking, tags the currently running thread with the KSE ID, chooses a new thread to run, switches to the new thread, and makes a system call to schedule a signal/upcall when the new threads quantum expires. o A KSE is woken up in the kernel. o Scheduler receives notification of a thread unblocking (finishing?) in the kernel. o At the request of the scheduler, the kernel schedules a timeout for the new quantum and resumes the now unblocked thread. > I will try make aset of diagrams that outline the state of various > objects related to a thread at various stages.. How about an animated GIF or MOV? ;-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message