Date: Mon, 27 Nov 2000 15:09:16 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: David Petrou <dpetrou@cs.cmu.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: thread model questions Message-ID: <20001127150916.R8051@fw.wintelcom.net> In-Reply-To: <20001127174120.G417@auchroisk.pdl.cs.cmu.edu>; from dpetrou@cs.cmu.edu on Mon, Nov 27, 2000 at 05:41:21PM -0500 References: <20001127171031.D417@auchroisk.pdl.cs.cmu.edu> <20001127142722.Q8051@fw.wintelcom.net> <20001127174120.G417@auchroisk.pdl.cs.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
* David Petrou <dpetrou@cs.cmu.edu> [001127 14:41] wrote: > thanks for the quick reply... > > > > 3. if preemptive, does that occur at user-level, or by the kernel? > > > (and how costly is it?) > > > > It's a mix, and very cheap. > > sounds pretty neat. is there a design document somewhere where i can > read up on this for fun? Not really, it's basically like most other userland thread packages out there but it is preemptive which a lot of the others aren't. > > > 4. if one thread makes a system call that could block for some time, > > > will another thread be automatically chosen? or will the whole > > > collection of threads sleep until the call returns? > > > > Latter. However our threads model wraps most syscalls so that you > > shouldn't block, you can still block on disk IO, however I have > > a proposal that I (or someone else) might implement in the near > > future to fix this. > > i think what you're saying is that for most of the cases, libc_r will > do the right thing when you make a syscall (like network I/O??). but > there are some cases like disk I/O where all the threads in the > process will block. presumably, if it these latter cases are a > bottleneck, someone will fix it, as you may fix the disk I/O case. Yes, here's the general idea of what I'd like to accomplish: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=130042+132666+/usr/local/www/db/text/2000/freebsd-arch/20001119.freebsd-arch Use aio to handle disk access, an accomplished coder could probably get the aio stuff done pretty fast, the hard part is the SIGFAULT where the kernel allows the userland to ask for faults to be serviced (through aio?) rather than servicing them automagically. > > > 6. if a thread or process (terminology sucks) enters the kernel, can > > > the scheduler preempt it and select another thread / process to > > > run? (q.v., what many people call having kernel threads.) or will > > > that process / thread dominate the system until it voluntarily > > > relinquishes the processor? > > > > Latter. > > hmm. so if i were writing a kernel module, i'd need to be careful to > not do too much work at a time. > > i assume you don't preempt processes in the kernel because there are > data structures that aren't properly protected from such preemption. > but won't you have to let more than one proc in the kernel at the time > to get scalable smp performance? In the -current branch we're approaching this, data structures are slowly being locked down. see: http://people.freebsd.org/~jasone/smp/ > so eventually, the synchronization > would have to go in. so when that happens, even on a uniprocessor, i > won't be able to depend on "owning" the kernel when i'm in it. if i > was right up to here, then it follows that if i want my code to work > in the future, i should do the synch necessary to ensure my own code > is reentrant. I'm suprised at how stable -current is at the moment, you should develop with it in mind and get yourself familiar with the smp primatives if you expect your kernel work to survive a 4.x->5.x transition. We do allow more than one process in the kernel, but only one process can be executing, meaning if a kernel thread sleeps on a resource another process can make headway in some other (or the same) codepath. > > > 7. are there other threads interfaces besides pthreads that i should > > > be aware of? what are the differences? e.g., assuming freebsd > > > supports a clone()-like interface, do some threads packages use it > > > while others do as much as they can without kernel support? > > > > the native threads are what conforms to the answers I have you above, > > there's a port called "linux-threads" in the ports collection to > > do what Linux does (clone()-like pid-per-thread) > > does linux-threads on freebsd allow preemption of processes in the > kernel? i assume the answer is no, but you didn't explicitly say so. I think you're placing a bit too much emphasis on this problem, we hope to have a pre-emptable kernel in the 5.x releases. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001127150916.R8051>