From owner-freebsd-hackers Sat Jul 29 16:33:36 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id QAA04794 for hackers-outgoing; Sat, 29 Jul 1995 16:33:36 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id QAA04786 for ; Sat, 29 Jul 1995 16:33:34 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA09991; Sat, 29 Jul 95 17:26:23 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9507292326.AA09991@cs.weber.edu> Subject: Re: pthreads To: bakul@netcom.com (Bakul Shah) Date: Sat, 29 Jul 95 17:26:23 MDT Cc: freebsd-hackers@freebsd.org In-Reply-To: <199507292251.PAA23854@netcom20.netcom.com> from "Bakul Shah" at Jul 29, 95 03:51:55 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk > > > While we're on the topic of threads, is there any work on getting > > > kernel level threads into bsd? > > > I think that this is a natural consequence of allowing kernel reentrancy > > in the SMP port... the kernel becomes internally preemption-safe. > > I think Marty Leisner is talking about multiple threads of > control in a single address space. If so, this can be > handled without kernel preemption. AFAIK kernel preemption > is really only required to handle realtime processes. Well, he said "kernel level threads". Unless you buy into the SVR4 definition, in which case a blocking operation will block the scheduling unit instead of becoming an async operation and a thread context switch. The SVR4 model has some serious drawbacks; if you do blocking calls in all your threads, you must have N kernel threads for N user threads. In general, there is little benefit to the SVR4 model other than causing people to program in a more event driven way (which could be argued) and a shared open file table and more complex signal and exception handling requirements. The Dynix "sfork()" interface provides the same functionality without adding silly restrictions on stack preallocation and scheduling quantum competition. > BTW, nice description of `priority inversion' w.r.t. > prioritized realtime processes on MP systems (in your other > message about Scheduling Algorithms). Why am I the only one who first found out about it from the IBM white paper? Does everyone else on the planet call it "priority inversion" instead of "priority lending"? 8-(. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.