On Wed, Sep 04, 2002 at 09:28:37AM -0700, Dan Kegel wrote: > I have no idea what Ulrich is planning for his linuxthread replacement, > but once it's out in the open, we can probably finally fix issues > like signal delivery.
Is there some public docs on this project ? I'm out of the loop as far as the Linux community goes in this area. ;) > Linux has been doing a pretty good job at keeping context switching > overhead low. The proof will be in the pudding -- say, in scores So has NetBSD. lmbench is within 2x of Linux and they're working SAs at this moment. They seem to have the best chance at getting a good threading model to happen in any BSD right now. The FreeBSD effort is much more ambitious technically and it's being done without any fulltime engineers. > on the Volanomark benchmark (or some better threading benchmark) on an > SMP system. ...A better threading benchmark... The JVM doesn't have the most direct threading subsystem glue code to the native API, so that could effect performance measurements. > My wager stands :-) I'm not a betting person. I think it's a disgusting habit. ;) Well, Linux is a couple of things working against it, namely a UTS (userspace threading system) can schedule a thread within 2 context switches and a call to the scheduler function when it encounters a sleep operation (via mutex block, sleep or blocking IO). Linux with clone() must cross a protected domain to block and reschedule which adds additional overhead that neither green threads nor FreeBSD's libc_r has. That's going to be a tough combination to beat and you've got to admit that, right ? ;) FPU/exception issues might make things more bizzare since architectural specific details vary across CPUs (brain dead x86) alter the time window balance between exception handling that crosses a protection domain, verses context switching. I'm not a low level CPU person per se, so I don't have answers nor any hints to what the answers would be in these cases. That's all. The proof is in the pudding or so they say. ;) bill ---------------------------------------------------------------------- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
