From owner-freebsd-current Fri Nov 6 11:50:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20223 for freebsd-current-outgoing; Fri, 6 Nov 1998 11:50:22 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20199 for ; Fri, 6 Nov 1998 11:50:11 -0800 (PST) (envelope-from james@westongold.com) Received: from [158.152.96.124] (helo=wgp01.wgold.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zbrtL-0004Zk-00; Fri, 6 Nov 1998 19:49:56 +0000 Received: by WGP01 with Internet Mail Service (5.5.1960.3) id ; Fri, 6 Nov 1998 08:56:45 -0000 Message-ID: <32BABEF63EAED111B2C5204C4F4F5020180A@WGP01> From: James Mansion To: Ville-Pertti Keinonen , James Mansion Cc: current@FreeBSD.ORG Subject: RE: Kernel threading (was Re: Thread Scheduler bug) Date: Fri, 6 Nov 1998 08:56:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Ville-Pertti Keinonen [mailto:will@iki.fi] > Subject: Re: Kernel threading (was Re: Thread Scheduler bug) > > James Mansion writes: > > > This is how OS/2 (at least) handles thread specific data, > > It's a kludge. > ... > > Entering and leaving the kernel is expensive, it would certainly not > be faster. Which was my point really. I'd rather waste the VM space and make the context switch more costly than have pthread_self and pthread_[sg]etspecific make kernel calls. Context switching is somewhat infrequent after all. If its not, the efficiency of these APIs is hardly your biggest worry. Given that we only really need a single pointer, then adjusting a well- known location in the currently executing kernel thread when it changes its binding to a user thread (whether this change is instigated by the kernel scheduler or the user-land part of the thread library) is fine and I feel stupid that it hadn't occurred to me before. ;-) It does mean that the page maps for multiple kernel threads executing in a process need to be different OR that a register is used somehow. As an application programmer it doesn't seem to matter, though as a C/C++ programmer I guess I'd rather see the dedicated use of a segment register since it seems likely to give the best performance and I'm not using them directly anyway. But I guess that's a whole ABI change. But, an ABI change that banished a difference between libc and libc_r and meant that I could write a thread-hot library subsystem without inflicting thread-aware compiles and links on the whole process would be a Good Thing IMO, and while this doesn't necessarily follow it would at least start to look more realistic. > > Non-Unix-like synchronization semantics can easily break the level of > isolation of Unix processes that makes them manageable. > Huh? I'm asking for pthread_*_[sg]etpshared, for P1003.1-1996. Are you objecting to them in principal? I can see some problems (say, can I close and reopen a mapped file which has an inter-process synch object in it and expect it to work?) but even if there are fairly stringent limits on the lifetimes they're still useful. James To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message