The author (Mark Russinovich) and I had a bit of an email exchange
yesterday regarding this article.
He is actually much more knowledgable about the state of threading
support in current kernel than I expected. He is aware of clone, and
the threads implementation in glibc2. He was NOT aware that many(most?)
of the other system libraries (such as Xlib) can be compiled to be
thread-safe, and are distributed that way by some distributions.
And just so you know, I have already argued that the side-bar was
incomplete and misleading...
Mr. Russinovich maintains that the threading support in the current
kernel/libraries is still not very well developed. Three significant
issues that were brought up were:
1 - IO operations are still serialized at a very high level in the
kernel. For example, it does not seem possible to read from a disk file
at the same time as a write() is being processed to a socket. Is this
correct, or did we miss some magic in the (un)lock-kernel() calls?
2 - Since the kernel does not have any notion of threads, it cannot
optimize things such as memory management. To quote Mr. Russinovich
directly:
I'm referring to the OS correct management of the physical memory
that has been assigned to the set of clones - it will trim/expand
the memory under the assumption that each is separate. This will
not cause incorrect behavior, but may introduce inefficiency and
is further evidence that the thread support has only begun.
Since I know nothing about memory management algorithms, I cannot say
what, if any, effeciency gains there could be by having a notion of
threads...others are invited to speak. :)
3 - Not directly related to threading support, but more of a "supporting
enterprise-level applications" issue: The current kernel does not
support asynchronus IO. E.g, there is no mechanism to issue write()s on
several file descriptors and get notified of the status of those
write()s at a later time.
The main goal of the async IO (at least, as far as this discussion is
concerned) is to avoid having a separate thread for each connected
client in a server process. One thread-per-CPU is the most effecient
state for a server process, because it avoids context switches. Async
IO would allow each thread to service multiple clients.
My response to the above is that similar functionality could be gained
with a combination of select() and non-blocking IO. However, this
combination would seem to generate excessive context switches and
user<->kernel space transfers, and non-blocking IO is not particularly
useful for disk files. It does have the advantage of getting immediate
error reporting however...
So, are context switches are so effecient that the one-thread-per-client
model is the best way to go, and there would be no real performance gain
in implementing async IO? If not, perhaps this should be a goal of the
2.3 series...
-- (Speaking for myself, not my employer...) Richard Fish Enhanced Software Technologies, Inc. Software Developer 4014 E Broadway Rd Suite 405 rjf@estinc.com Phoenix, AZ 85040 (602) 470-1115 http://www.estinc.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/