From owner-freebsd-smp Tue Dec 8 13:52:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15811 for freebsd-smp-outgoing; Tue, 8 Dec 1998 13:52:44 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15805; Tue, 8 Dec 1998 13:52:37 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA07587; Tue, 8 Dec 1998 14:52:16 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd007090; Tue Dec 8 14:51:42 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA25595; Tue, 8 Dec 1998 14:51:01 -0700 (MST) From: Terry Lambert Message-Id: <199812082151.OAA25595@usr09.primenet.com> Subject: Re: Pthreads and SMP To: michaelh@cet.co.jp (Michael Hancock) Date: Tue, 8 Dec 1998 21:50:55 +0000 (GMT) Cc: alk@pobox.com, tlambert@primenet.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Dec 8, 98 05:22:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > : One reason I haven't piped up on this (I *do* have the scheduler > > : changes for CPU affinity working, actually) is that apart from > > : that, there's still the issue of the per thread stack. > > : > > : I am not very satisfied nor happy with the allocation of stack in > > : the same VM space in each thread (for reasons of stack autogrowth), > > : and I would want to address that before anything else. > > > > Yikes! Surely you are not proposing to place the stacks of > > distinct threads in distinct address spaces?! This would > > impact application portability negatively. > > I think he's talking about stacks for kernel execution contexts (kernel > threads). No; that's a problem, too, but it's less of a problem. If you think in terms of an async call gate, all blocking calls in a reentrant kernel would be made on a kernel stack from a kernel stack pool, with guard pages and the ability to manage the VM space for the call by fault (to grow the kernel stack). In other words, the kernel stack is not associated with the kernel process (scheduling context, actually, since threads in a kernel thread group should have the same "thread group ID" [PID]). In the current implementation using the glue code, each kernel thread is a process that shares a number of identical proc struct pointers with its nominal "parent" (peer thread that created it). > #ifdef SOLARIS25 > thr_setconcurrency(2); > #endif > > Digital UNIX is m-n and doesn't have these peculiarities and I thought > they were resolved in Solaris 2.6. They are; the usage model is such that there is a sperate thread for reception of a signal causing the spawning of an additional kernel thread. This allows them to avoid the m:n "n blocking calls" deadlock by spawning another kernel thread to handle the load. It's what Microsoft calls their "apartment threading" model, where user space threads are allowed to go into the kernel, and kernel threads are instances to back them while they are there, as necessary. Kind of like the cube visiting flatland. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message