Date: Tue, 8 Dec 1998 21:50:55 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: michaelh@cet.co.jp (Michael Hancock) Cc: alk@pobox.com, tlambert@primenet.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP Message-ID: <199812082151.OAA25595@usr09.primenet.com> In-Reply-To: <Pine.BSF.3.95LJ1.1b3.981208170921.370A-100000@sv01.cet.co.jp> from "Michael Hancock" at Dec 8, 98 05:22:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > : 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812082151.OAA25595>