Date: Tue, 3 Nov 1998 14:06:45 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Daniel Eischen <eischen@vigrid.com> Cc: james@westongold.com, peter@netplex.com.au, current@FreeBSD.ORG, jb@cimlogic.com.au, lists@tar.com Subject: RE: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <Pine.BSF.3.95.981103135641.1112F-100000@current1.whistle.com> In-Reply-To: <199811032133.QAA22300@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
here's the trick.. the address space is presently a separate entity from the process scheduling structures. the two are linked by a single pointer really. The address space structures have a reference count and 'threads' are implemented by simply making many scheduling entities point to the same addres space structure.. if you make the threads have differnt pages, then either the addres space needs to be 'munged' on each reschedule (where is the page swapped out to since where it's swapped to depends on the object mapped into the address space), or you need to have multiple different address spaces sharing a lot of 'objects' which is a lot less efficient. On Tue, 3 Nov 1998, Daniel Eischen wrote: > > > From: Peter Wemm [mailto:peter@netplex.com.au] > > > Sent: Sunday, November 01, 1998 3:30 PM > > > ... > > > - a "process" (struct proc) would have one or more threads, > > > all using the > > > same address space, pid, signals, etc. > > > ... > > > > 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. easier to simply have a single pointer in a known address that gets rewritten by the kernel on scheduling.. probably actually an array of them, (one per cpu) with a 'getcpunumber()' to allow the thread to work out which it should use. in MACH they had several techniques.. one of which was used in the user-land threads, whuch was that each stack was alligned on some boundary (e.g. 0x100000 byte alligned) and the thread specific storage was always at (e.g. SP & 0xfff00000) (or some similar thing). > > What about same process threads executing on multiple processors? > > common_address[MAX_CPUS] ? > > > 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. > > > > > > 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). > > > > Can I ask (plead, really) for any effort in this area to > > consider the support for inter-process synchronisation as well > > as intra-process? > > Dan Eischen > eischen@vigrid.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > 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?Pine.BSF.3.95.981103135641.1112F-100000>