Date: Mon, 27 Nov 2000 17:41:21 -0500 From: David Petrou <dpetrou@cs.cmu.edu> To: Alfred Perlstein <bright@wintelcom.net> Cc: David Petrou <dpetrou@cs.cmu.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: thread model questions Message-ID: <20001127174120.G417@auchroisk.pdl.cs.cmu.edu> In-Reply-To: <20001127142722.Q8051@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Nov 27, 2000 at 02:27:22PM -0800 References: <20001127171031.D417@auchroisk.pdl.cs.cmu.edu> <20001127142722.Q8051@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > > 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. > > 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? 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. > > 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. > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] thanks, david 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?20001127174120.G417>