Messages in this thread | | | Date | Mon, 23 Sep 2002 14:32:21 -0700 | Subject | Re: [ANNOUNCE] Native POSIX Thread Library 0.1 | From | Bill Huey (Hui) <> |
| |
On Mon, Sep 23, 2002 at 08:30:04AM -0700, Larry McVoy wrote: > > No matter how fast you do context switch in and out of kernel and a sched > > to see what runs next, it can't be done as fast as it can be avoided. > > You are arguing about how many angels can dance on the head of a pin. > Sure, there are lotso benchmarks which show how fast user level threads > can context switch amongst each other and it is always faster than going > into the kernel. So what? What do you think causes a context switch in > a threaded program? What? Could it be blocking on I/O? Like 99.999%
That's just for traditional Unix applications, which is only one category. You exclude CPU intensive applications in that criticism, media related and otherwise. What about cases where you need to balance a large data structure across large number of threads or something like that ?
> of the time? And doesn't that mean you already went into the kernel to > see if the I/O was ready? And doesn't that mean that in all the real > world applications they are already doing all the work you are arguing > to avoid?
IO isn't the only thing that's event driven. What about event driven systems that depend on a fast condition-variable ? That's very cheap in a UTS (userspace thread system), 2 context switches, a call to thread-kernel to dequeue a waiter and releasing/aquiring some very light weight userspace locks. And difficult to beat if you think about it.
So that level of confidence in 1:1 is a intuitively presumptuous for those reasons.
But if you're architecture is broken or exotic...then it gets more complicated ;)
bill
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |