From owner-freebsd-arch Wed Nov 24 14:41:27 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 6ED7214BDA for ; Wed, 24 Nov 1999 14:41:17 -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 XAA10661 for ; Wed, 24 Nov 1999 23:41:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36502 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:41:15 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0D27914BDA for ; Wed, 24 Nov 1999 14:41:08 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA53172; Wed, 24 Nov 1999 14:40:52 -0800 (PST) Date: Wed, 24 Nov 1999 14:40:52 -0800 (PST) From: Julian Elischer To: "Louis A. Mamakos" Cc: Daniel Eischen , Matthew Dillon , "Daniel C. Sobral" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think matt ha sa point but it doesn't necessarily cover all the requirements that complying with posix threads brings us. The system we suggest includes an escape mechanism whereby the blocked KSE is 'replaced immediatlyby a new one, that is made available to the Userlevel Thread Scheduler (UTS). If this feature is not enabled (the appliation has to turn it on when it has enough of itself set up to handle it) then we effectively have Linux threads, or with only one process, our current threads. here are some common points that I think everyone agrees on: The proc structure get's broken down to separate out those parts needed to schedule. (i.e. context etc) When a KSE blocks, that stack and context are effectively frozen, just as they are now. where we differ is what happens next. In Matt's system new KSE is created and run and a different userland context is chosen and scheduled by the kernel on that KSE. (as it has all the userland contexts stored somewhere. In ours, a new KSE is created and run and the UTS is invoked which does the same job but in userland. In Matt's system a 'yield()' call is a system call, where in ours it's something similar to a setjmp + calling the UTS. In Matt's system creating a new user thread context requires making a syscall (to save the context of whichever thread doesn't continue after the call). The difference is in who has access to what information. The same task is being done in each case, but where? In the "kernel thread Scheduler" (KTS?) model the kernel has to know all the information required for scheduling these threads. The Userland needs to know this too to some extent to decide when to migrate threads around between processors and how and when to change priorities. (which it needs to do via syscalls). The sceduling methods are liitted to what the kerlel supports. In the UTS model, the kernel is oblivious to what threads are being scheduled onto the KSEs. Both systems could work. I think we need pictures :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message