There’s been a slight conversation about threading, where Jeroen Ruigrok van der Werven mentioned he would want hybrid, or M:N threading. Miguel Mendez chimed in that 1:1 threading, while not as spiffy, is easier to implement and Sten Spans posted a link to this PDF describing 1:1 threading in Linux. (I assume – haven’t read it yet) Matt Dillon brought up a larger issue: asynchronous syscall messaging support is needed before any of this thread work can be done.
8 Replies to “Threading thread”
Comments are closed.
I seem to recall reading a post from Matt saying that what he’s doing is essentially M:N. From all I’ve read, M:N threading is theoretically ‘better’ than 1:1 threading, and the only reason why 1:1 works better in Linux is because of some architectural wackyness in Linux that make s M:N perform more poorly than it should otherwise.
(I’m no expert obviously, just going by everything I’ve read on the topic)
Personally I’d go with M:N, and I hope that DragonFly actually does. But then who says that we can’t do both just as FreeBSD has done?
Solaris (in version 9 i think) switched from M:N to 1:1 so the arguments for 1:1 are a lot stronger than you think.
One of the followups to the threading thread noted that the reason Solaris went 1:1 was organizational, not mechanical. 1:1 wasn’t necessarily better, but it was easier to implement. Of course, this is all hearsay unless a Sun employee wanders by.
I think that the real issue here is a matter of philosophy. DragonFly doesn’t have one. Many of the project’s goals are quite well defined, but a number of important issues, like this threading one, are going to be a bit of a headache because of differing points of view.
A lot of folks want 1:1 threading done in DragonFly because it’s easier to implement (easier to debug?) whereas Matt has said that “n:m is always better then 1:1 because thread switches within each virtual cpu (where the virtual cpu is represented by a single user process) require no context switch into the kernel at all.” It seems like a lot of the project’s goals were choses as they would eventually allow new features to be implemented more easilly than the same features could be added to (for example) FreeBSD by removing needless complexity. This is one of the arguments for using 1:1 threading preferentially on DragonFly.
My argument is that while needless complexity should be avoided, some things should not be avoided because they are complex. If N:M truely is better than 1:1 threading, than it *should* be implemented.
I guess the philosophy that I am proposing would go something like this: “Use the minimum amount of complexity needed to do the job right” as opposed to going the path of least resistance.
That’s just my thoughts on the matter. DragonFly already stands well enough on it’s own, regardless of my own small opinions.
FreeBSD 5 had both a 1:1 and M:N model built; there’s no reason (other than resources) that can’t be done for DragonFly too.
I supposed schedule is another issue; which can get done first? It’ll be Matt’s call, I think.
Here is some of the reasoning on LWP (ie. 1:1 threading):
http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf
This Sun employee (and author of multithread.pdf) was just “wandering by”. Having been an advocate of MxN for many years (largely, because that was one of our differentiators), I was treading a very fine line. I think the paper makes it clear that I don’t think 1:1 is superior as a _model_, but that our MxN _implementation_ was past its sell-by date. The switch was entirely pragmatic. I personally had to drag quite a few folk kicking and screaming to the right decision. We have never looked back.
Since then we’ve added other cool stuff like: compiler support for TLS, posix_spawn() and POSIX spin locks. But our crowning achievement is to get rid of libthread altogether by folding it into libc. None of this would have been possible in the same short time if we had persevered along the MxN route.
You can play with all* of this cool new stuff today via the Solaris Express program (which provides early access to Solaris 10 as we develop it). See http://www.sun.com for more details. Sorry, I didn’t mean this to turn into a marketing opportunity :)
* currently, only the Forte SPARC compiler supports TLS, but we hope to fix that soon! Actually, with the right patches, TLS is available right back to /usr/lib/lwp in Solaris 8.
Since everyone loves acronym decryption, Google says TLS is Thread Local Storage, and http://people.freebsd.org/~marcel/tls.html might be one of the more applicable hits.
I’m going to take a wild guess and say that a) 1:1, being easier, doesn’t “prove” as much (when part of DragonFly’s intent can’t avoid being to ‘prove’ DragonFly is a good foundation for implementing this sort of complexity), and b) the general vibe I get is that Sun believes in real_threading_everywhere (which demands a stable, understandable threading implementation as a prerequisite for shaking down the programs using), while everyone in free-land doesn’t expect or worry to the same extent about nonthreaded apps migrating overnight.
[In other words, BSDs with cool new kernel architectures are ‘doomed’ to tackle M:N because that’s where the fun is. Since 1:1 is ‘easy,’ it’s what people fall back on if progress appears to stall, as seen with FreeBSD… I’d venture that all the banging and learning on the ‘harder’ problem is what lets the 1:1 implementations appear so fully-formed?]