Date: Wed, 24 Nov 1999 14:40:52 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Daniel Eischen <eischen@vigrid.com>, Matthew Dillon <dillon@apollo.backplane.com>, "Daniel C. Sobral" <dcs@newsguy.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.BSF.4.10.9911241405570.11412-100000@current1.whistle.com> In-Reply-To: <Pine.BSF.4.10.9911241207100.11412-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911241405570.11412-100000>