Date: Fri, 6 Nov 1998 08:56:36 -0000 From: James Mansion <james@westongold.com> To: Ville-Pertti Keinonen <will@iki.fi>, James Mansion <james@westongold.com> Cc: current@FreeBSD.ORG Subject: RE: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <32BABEF63EAED111B2C5204C4F4F5020180A@WGP01>
next in thread | raw e-mail | index | archive | help
> From: Ville-Pertti Keinonen [mailto:will@iki.fi] > Subject: Re: Kernel threading (was Re: Thread Scheduler bug) > > James Mansion <james@westongold.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32BABEF63EAED111B2C5204C4F4F5020180A>