Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux 2.6 Multithreading Advances

Posted by michael on from the code-warriors dept.

chromatic writes "Jerry Cooperstein has just written an excellent article explaining the competing threading implementations in the upcoming 2.6 kernel for the O'Reilly Network."

4 of 194 comments (clear)

  1. Re:Yeah, yeah, yeah by Anonymous Coward · · Score: 0, Funny

    I hear they just added the keyboard driver. It's the most advanced keyboard driver known to man.

    Now all they need is some kind of output device.

  2. Re:GNU/HURD by Anonymous Coward · · Score: 3, Funny

    "Just like Communism, GNU/HURD will never take off."

    More realistically, like communism GNU/HURD is a great idea in theory, but the only available example right now is run by fascist lunatics and doesn't work...

    AC because I'm too cruel

  3. Re:GNU/HURD by Anonymous Coward · · Score: 1, Funny
    Just like Communism, GNU/HURD will never take off.

    Please don't compare GNU/HURD to communism. They are similar in that both sound good in practice, but have problems in the real wordld. However, the similarity ends there. Communism was responsible for loss of life and liberty for millions of people killed and improsoned, Hurd, However, is released under GPL, and is therefore even worse.

  4. Re:Non-threaded programs by Anonymous Coward · · Score: 1, Funny
    Wrong. Every context switch burns hundreds, if not tens of thousands, of clock cycles. As the parent comment said, changing from single threading to multithreading on a uniprocessor system necessarily reduces performance. How bad it does depend on the program design, but there is always a slowdown

    Jesus fucking christ, with a modern multitasking OS, the OS will be swapping the process anyhow, and that's much more expensive than threading context switches. Or are you advocating the use of a cooperative multitasking OS (like MacOS 7) or a single-threaded OS (like MS DOS)?

    Wrong again. It's trivial to run multiple copies of a single-threaded program on the different CPUs, and let them interact over IPC.

    at which case it is no longer (collectively) single-threaded. Of course, this does seem like a slashdot solution (a complex and over engineered solution to a non-existant problem)