Date: Mon, 13 Dec 1999 22:58:20 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Terry Lambert <tlambert@primenet.com> Cc: adsharma@sharmas.dhs.org, arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <3855C05C.A59F6B47@vigrid.com> References: <199912140237.TAA01908@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > As an unfortunate historical note, SunOS 4.1.x supported something > called "liblwp", which was effectively a wrapper for turning a > blocking I/O call into a non-blocking I/O call plus a threads > context switch. Sun added aio_read/aio_write/aio_wait/aio_cancel > system calls, as well as a helper system call for dealing with > the user stack, and which knew about SPARC register windows; the > University of Washingtom technical report "User space threads and > SPARC Register Windows" (1992) describes the implementation. Since you mentioned aio_read/aio_write... Should these targets for a rewrite once our P's and Q's are in place ;-) I guess it'd even be possible to pull them out of the kernel and place them in libc, though I don't know that we'd want to. > > I dunno. It seems easier to me to implement SA from the start, > > concentrating on eliminating much of the extraneous code in libc_r. > > I'd start with making it only work for one process or Q. The > > userland part of this seems really easy to me. Once that works, > > I'd add the ability to have multiple Q's. > > This is what looked right to me, and I think that Jason Evans > agreed. The intent was to not break out "Q" until later, as > part of the scheduler work. Terry, I'm surprised. We actually agree :-) > For one thing, we already have the Linux threads implemented > (it can be loaded as a kernel module). For another, kernel > threads backing user space threads is a horrible implementation, > and has all sorts of problems with thread group (process) affinity > when deciding who to run next on a partially consumed quantum. > Adding thread group affinity to a kernel scheduler is a sure way > to shoot your leg off. > > I think that this is at least natural, if not the order I would > choose. Much of the hardest work is allowing the process to be > on a multiple run queues (or the same run queue, multiple times). > This work could even be debugged on a UP machine, where you > stuff the same process into a single scheduler several times > (indeed, this is necessary for PTHREAD_SCOPE_SYSTEM thread > priorities on a uniprocessor machine). > > This seems to me to most resemble the shared library issues, > where it's better to do it right the first time than it is to > take a bogus implementation (e.g. the System V shared library > style implementation, which ate a chunk of address space for > each version of a single library, and the same for each library, > as they had to be non-PIC code mapped to the same location in > all processes). Waiting on Jeffrey Hsu's patches for PIC in > GCC (actually, released in support of LKMs, which needed PIC) > was The Right Thing To Do(tm). > > > > If we stick to the POSIX threads interface strictly, we shouldn't be > > > afraid of getting stuck with one of the implementations. > > > > > > Other concerns that were expressed - crossing protection boundaries too > > > often to pass messages about blocking and rescheduling. Matt Dillon > > > responded that these messages could be batched and made more efficient. > > > > I agree. It seemed like the SA paper went to extremes in notifying > > the UTS of unblocked threads. I think we can do this at more opportune > > times, like when a Q is resumed or on a user->kernel crossing. I don't > > know that we want to be interrupting a Q while it is running a thread > > just to notify the UTS that another thread has unblocked in the kernel. > > Julian had a nice discussion with Jason (and later Matt and me) on > this topic. The basic idea was to run the threads up to the user/kernel > boundary, but not farther. At that time, the call has effectively > returned all but the CPU on which it is running to user space, and > a nice optimization is that the kernel stack associated with the KSE > can be released. This would allow hundreds of thousands of the > things, a possibility on a heavily loaded system. Actually, after re-reading the SA paper, this is what it suggests. Unblocked threads are temporarily resumed to the point that they either block again in the kernel or reach the point where they would leave the kernel. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3855C05C.A59F6B47>