Date: Sun, 1 Nov 1998 10:54:28 -0500 (EST) From: Chuck Robey <chuckr@mat.net> To: Peter Wemm <peter@netplex.com.au> Cc: Daniel Eischen <eischen@vigrid.com>, lists@tar.com, current@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <Pine.BSF.4.05.9811011041430.306-100000@picnic.mat.net> In-Reply-To: <199811011529.XAA25055@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 Nov 1998, Peter Wemm wrote: > > I'd like to help in this effort, but I'd first like to see > > exactly what threading model is desired. Do we want a Solaris > > lightweight process model with the ability have both bound > > and unbound user threads? Or do we want libpthread to keep > > a one-one mapping of threads to kernel threads? > > I'm not familiar with Solaris threads but have seen the man pages for the > SVR4.2-whatever-it-is-this-week as used in Unixware. > > What I had in mind was something along the lines of: > - the kernel context switching entity would become a 'thread' rather than > a 'proc'. > - a "process" (struct proc) would have one or more threads, all using the > same address space, pid, signals, etc. > - The logistics of doing this are ugly. I don't expect that a global > 's/sturct proc/struct thread/g' would go down well. > - the boundaries between the present 'struct proc', pcb, upages, etc would > get muddied a bit in the process. The context that a thread would need > would be something like a superset of the pcb at present. > - A thread would have just enough context for making syscalls etc. > - context switching between threads would be bloody quick, as good or > better than switching between rfork shared address space siblings. > - There would be one kernel stack per thread, up to a limit of the number > of present CPU in operation. If you had 4 cpus and 1000 threads, you > still only need 4 stacks and other associated things (PTD etc). > - It would be nice to have some sort of cooperative kernel<->user > scheduling interface so that it would be possible to have the libpthread > "engine" schedule it's pthreads onto kernel threads. Suppose one wants a > few thousand pthreads, but only realistically needs 10 or 20 of them to > block in syscalls at any given time. The way it's put, it *seems* like you're saying that a thread needs more context than a proc, but since the proc context really must be shared among all it's threads, you wouldn't want to duplicate the proc context, you'd just want to make the right proc context available to the right threads, right? The idea is that threads have less context, meaning less complicated context switching (and lower overhead for that context switching), right? The idea about each thread having it's own kernel stack seems unavoidable, but that stack could be pretty limited in size, and actually settable size, right? I'm wondering about memory allocation here for threads ... in a proc now, if you run out of stack, it grows for you. I think that would be too big a hammer on the system for each thread, wouldn't it? If a thread ran out of stack, would it just give a signal indicating the problem, and let the thread itself (or a thread managing thread) handle new stack problems. I mean, threads handle stack setup themselves, when they start, unlike processes, and it ought to be as lightweight as possible. I'm not an expert, these are questions. I don't want threads to become little processes with implicitly shared memories, I want them to be lightweight, as they were originally intended. The only reason to move to kernel threads at all is to make the signal management lighter in weight, and get single thread blocking on syscalls, right? I guess I'm trying to emphasize "lightweight". I'm going to go hunting in the mail archives, Terry *must have* written one of his email-books on this sometime. > > I'd love to get more involved in this from the kernel side of this, but > surviving from day to day is number one priority at the moment. > > Cheers, > -Peter > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- 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.4.05.9811011041430.306-100000>