In message <[EMAIL PROTECTED]>,
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
>"Ronald F. Guilmette" wrote:
>>
>> As I say, my understanding is that FreeBSD still doesn't have real and/or
>> complete thread support in the kernel. So if you have a multi-threaded
>> application and one thread blocks (e.g. on I/O) then the whole thing is
>> blocked.
>
>Ouch! That's just not true.
>
>FreeBSD has userland threads. This is faster than kernel threads, but
>has two disadvantages. First, it doesn't make use of SMP. Second, they
>all compete together as a single process for CPU time. It seems some
>programmers prefer to use threads to increase their process' CPU time
>than lowering the process' priority.
Well, my apologies for mis-speaking.
When I say ``real/complete threads support'', I usually mean threads that:
o will in fact get distributed across multiple processors in an
a multiprocessor system (if the kernel support multi-processors
at all that is), and threads that...
o will in fact compete against all other threads/processes in the
system for CPU slices, and threads that...
o can block on I/O while other threads in the same process continue
to be scheduled.
Now you are saying that at present, the FreeBSD implementation of threads
has at least the last of these three attributes. That's the first _I've_
heard of that, but it is certainly encouraging, and it may cause me to
start doing some stuff with threads under FreeBSD.
I would really be very grateful however if _someone_ would explain to me
the actual low level-mechanics of how this works, i.e. how one thread in
a ``multi-userland-thread'' process can manage to get control and/or a
CPU time slice when and if a different thread within the same process
gets blocked awaiting some I/O completion.
For example, take the simplest possible case.... I have a process that
is running two threads. One of those threads issues a call to read(2)
to read characters from some interactive device... like a terminal.
But no characters are yet available. So that thread blocks on the I/O
request.
In this simple scenario, how does the other thread (which is part of this
same process) get control back?
Give the other assertions that you've made about threads, i.e. that (in
recent releases of FreeBSD at least) they DO NOT compete with each other
and/or with other processes on a system-wide basis, I really have a little
trouble understanding how the second thread in the scenario I described
would manage to get control back.
The kernel doesn't even know that that second thread exists as a separately
schedualable entity, right? So who (or what) exactly is going to schedule
it for execution when the first thread becomes blocked on I/O?
>Not to dismiss FreeBSD's kernel problems, but that thing about blocking
>is absurdly untrue.
I'll take your word for it. I juts wish that I could understand how that
could be the case.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
