Date: Thu, 2 Dec 1999 13:46:14 -0800 From: "David Schwartz" <davids@webmaster.com> To: "Terry Lambert" <tlambert@primenet.com> Cc: <freebsd-chat@FreeBSD.ORG> Subject: RE: threads.... Message-ID: <000101bf3d0e$a7e8c6b0$021d85d1@youwant.to> In-Reply-To: <199912022118.OAA28482@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > You're joking right? Or do you think that real-world server > applications > > don't mind if you freeze everything while the kernel services a > page fault > > or reads a file from a slow disk? I'm not sure you read what I wrote, since you didn't respond to it. > The question is why the application is threaded; there are a > number of reasons to thread an application: > > 1) In order to have seperate, similar (or identical) "tasks" > operating in parallel. In other words, in order to obtain > multiple program counters. > > NB: I believe this is th ICQ case This is the trivial case for threads. This can clearly be done in user-space (and, IMO, should be). > 2) To achieve some level of concurrency on a UP system by > interleaving rather than serializing I/O. > > NB: This can be accomplished using async I/O > > NB: This can be accomplished using non-blocking I/O, > if the systems I/O subsystem is built to take > the hint that it got and queue the read-ahead > before returning the "EWOULDBLOCK" to user space Tell me, how do you handle a page fault asynchronously? Who does the kernel return the 'EWOULDBLOCK' to? > 3) To achieve SMP scaling by giving the kernel scheduler > discrete object to apply the quanta from more than one > CPU, in order to get multiple CPUs into user space in > a single process. Actually, this can be essential in the UP case as well. You may have a high-priority subtask that needs to be scheduled a certain way and a lower-priority subtask the needs to be scheduled somewhat different. It can be nearly impossible to do this in a user-space scheduler. > Therefore, the only reason for kernel threads on FreeBSD, Linux, > or BSDI at this time is SMP scalability. As a means of SMP > scaling, this approach leaves a hell of a lot to be desired, > since it does not address the CPU affinity, thread group affinity, > or significantly increased context switch overhead issues. Actually, it's also needed for portability. There's an awful lot of code out there written for kernel threads. It's a very non-trivial task to make that use asynchronous I/O just for FreeBSD. So until FreeBSD gets real kernel threads, that code will continue to run pitifully on it. Also, making all your I/O non-blocking (even in the cases where it appears through static analysis that it's very unlikely to block) is very expensive computationally. You have to be ready to 'hold your place' everywhere. If the block is likely, it's worth it. But if the block is extremely rare, the cost of placeholding (just in case you block) will be enormous. The only sane way to resolve it will be to do most of your I/O synchronously, and you'll be left vulnerable to ambush on a surprise block, say due to a failing local disk drive. > Hope that answers your question; if it doesn't, please see the > current discussion on -arch in the mailing list archives to see > what a real low overhead, SMP scalable, threading system has to > look like. In the interests of keeping the signal to noise ration on -arch as high as possible, I don't follow that newsgroup. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000101bf3d0e$a7e8c6b0$021d85d1>