Date: 05 Nov 1998 09:39:06 +0200 From: Ville-Pertti Keinonen <will@iki.fi> To: James Mansion <james@westongold.com> Cc: current@FreeBSD.ORG Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <8667cud1wl.fsf@not.oeno.com> In-Reply-To: James Mansion's message of "4 Nov 1998 18:54:39 %2B0200" References: <32BABEF63EAED111B2C5204C4F4F50201804@WGP01.newsgate.clinet.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
James Mansion <james@westongold.com> writes: > I'd like to suggest that threads (at least kernel threads) > should share an address space EXCEPT for a page (or maybe > more than one) that will have a common address in each thread. > This is how OS/2 (at least) handles thread specific data, > and so far as I can tell it is potentially much cleaner > for TSD, including errno. It's a kludge. > Any user-level multiplexing would need to save/restore this > data on task switch of course and a kernel-assist that changes > the memory map might be faster (or might not, dunno). Entering and leaving the kernel is expensive, it would certainly not be faster. It's not a good idea for kernel threads, either. The kernel either needs to change a page mapping in the process map or switch to a thread-specific map. The latter would make threads almost equivalent to processes and the former is not good for SMP, because the process memory map is prepared to run only one thread at any given time. As a "fix", each process could have as many page directories as there are CPUs, but creating them "on-the-fly" each time would be too slow and letting them exist while not running the process could end up costing two pages per extra cpu per multithreaded process in addition to the actual thread-specific pages. It doesn't scale well. > Can I ask (plead, really) for any effort in this area to > consider the support for inter-process synchronisation as well > as intra-process? Non-Unix-like synchronization semantics can easily break the level of isolation of Unix processes that makes them manageable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8667cud1wl.fsf>