Subj : Re: threaded application scalability question To : comp.programming.threads From : David Schwartz Date : Wed Feb 16 2005 02:30 pm "Marcin 'Qrczak' Kowalczyk" wrote in message news:87psz019ao.fsf@qrnik.zagroda... > "David Schwartz" writes: >>> This depends on the implementation of threads. OS-level threads will >>> probably be too heavy when there are several thousands of them, but if >>> the given language implements threads in userspace, they might scale >>> exactly as hand-written dispatching could - because it's essentially >>> the same, only the source code is written more conveniently. >> Not likely. What happens when there's a page fault, say due to a rare >> code path being hit? > Then all threads are stopped until the code is swapped in. Like if it > was written without OS threads. Right, so it won't scale exactly as hand-written dispatching would. It will suck. > What do you propose instead? The most efficient method is also the > most complex: have some number of OS threads (more than processors > but not much more) and distribute work among them. It's hard to say > whether requirements of a particular application really need this. That is not complex. You write the code to do it once and use it over and over on every server you right for the rest of your life. > BTW, the scheduler in Kogut now uses epoll() on Linux when it's > available. I don't know how to test the scalability without a > sophisticated real-life application though. An obvious limitation is > that threads don't have settable priorities, and CPU-bound threads > have an unfair advantage over threads which do lots of synchronization. > I don't know how important is this in practice, or how it should be > properly designed. Perhaps I should use it first for something real... It should not matter. You get to code what each thread does, so you should not care which thread runs. Just make whichever thread happens to run do whatever it is you most need to do. DS .