%
%I have searched the archive for a while and still have some confusions
%about this subjects:
%
%(1) Some people say "For I/O bound activity, kernel threads are a really
%bad idea". But I read the following passage from else where:
%
%Kernel threads perform better in I/O-intensive applications because system
%call can be blocking for kernel threads (so there is only one
%user-to-kernel and kernel-to-user transition per I/O operation rather than
%two).
%
%So which one is the correct answer? I know there is only userland thread
%in FreeBSD, but I would like to know the answer.
%
%(2) User threads are supposed to be faster than kernel threads in context
%switch. But since we poll devices during each context switch, it is
%actually slower (poll() is the extra system call). Is this correct?
%
%(3) Can I do cooperative thread scheduling on FreeBSD? I guess the
%constant SCHED_RR (round robin) means preemptive. How about SCHED_FIFO
%and SCHED_OTHER defined in posix4/sched.h? Can I choose from them? In
%the case of SCHED_RR, I still do part of scheduling by routines like
%yield(), cond_signal(). Am I right?
%
%Any help is appreciated.
Excellent questions.
However, what is not stated is perhaps the most important (to me,
and other people burning up and showering down $$$). C++ programmers
use threads to share class members. In that context, the POSIX
realtime scheduling classes (SCHED_*) are quite useful, albeit abstractly
for now.
IMNSHO, focusing on fine-grained benchmarks ("perform better") for
an execution model based on C processes may be misleading in the
realistic broader picture.
Russell
%-Zhihui
%
%
%
%
%To Unsubscribe: send mail to [EMAIL PROTECTED]
%with "unsubscribe freebsd-hackers" in the body of the message
%
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
