> On Fri, 19 Jun 1998, Alex Belits wrote:
>
> > Or threading is a workaround for lack of proper nonblocking I/O handling
> > in applications. Multithreading and nonblocking I/O are two opposite
> > concepts when it comes to I/O handling.
>
> They're orthogonal concepts, not opposite. non-blocking I/O is one way to
> implement a userland thread library; and a way to implement a hybrid
> user/kernel library. Is that what you meant?
I mean that they can be used separately, providing the same
functionality, but their combination is rare, not because it can't be
efficient, but because they represent different styles. Some programmers
feel uncomfortably designing programs where they never can do things in a
"natural" order of actions performed on the same object, so they don't use
nonblocking I/O that can leave things incomplete and require doing
something else at any moment. Others can accept that, but have problems
with seeing multiple copies of themselves existing in one universe,
trying to live independently of each other ;-), so they see
"unnatural order" of nonblocking I/O operations as the lesser evil.
Combination of two are never required to achieve the functionality, and
mostly appear when the OS or libraries have significant bias toward one of
model, and programmer is biased toward another one. Performance
requirements may change this, however I still don't believe in "threads
will make everything faster", unless it has " on NT and Solaris"
immediately following it.
Of course, threads can be implemented through nonblocking I/O, and it's
possible to even implement nonblocking I/O through blocking one and
multithreading, however the need of such tricks is more related to
compatibility requirements than to anything else.
I admit that personally I am biased toward nonblocking I/O.
> Like you allude to, using blocking I/O exclusively can actually be
> somewhat of a crutch. Remember for each thread, (user, kernel, or hybrid)
> you have a stack, plus a structure that describes the thread. Multiply
> that by the number of I/O streams in progress and you really start
> threatening your L2 cache... once you've got more active data than your L2
> cache can hold performance drops off drastically.
I/O streams have some data that describes them in any model, explicitly
or implicitly. Various buffers, associated with every stream, seem for me
to be more of a threat for cache than threads descriptors or structures
that describe connections in nonblocking programs.
-- Alex
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu