Slashdot Mirror

← Back to Stories (view on slashdot.org)

NetBSD Now Has Native pthreads!

Posted by timothy on from the restless-threads-are-next dept.

jschauma writes, quoting the NetBSD changelog, was one of several people to point out that "Jason Thorpe has merged the nathanw_sa branch with -current. NetBSD now has a high performance, modern kernel thread implementation using Scheduler Activations in the main source tree. This work was performed by Nathan Williams with contributions by several other developers."

7 of 37 comments (clear)

  1. Does this mean...? by SixArmedJesus · · Score: 2, Interesting

    Does this mean that NetBSD can now support SMP, or am I just way off here... ?

    --

    *slight crashing sound*
    1. Re:Does this mean...? by sporty · · Score: 3, Interesting

      You can have seperate processes running on seperate processors without the use of threads. All it means, is that there is native code within netbsd itself to support threads.

      Threads are the ability for a process to run more instance of itself, sharing all data without starting a new process. With fork, all data is seperate.. two forked processees, for the most part, cannot affect each other.

      --

      -
      ping -f 255.255.255.255 # if only

    2. Re:Does this mean...? by beholder77 · · Score: 5, Informative

      NetBSD has had SMP support for a few platforms in the -CURRENT branch for a while now (sparc, vax and alpha for sure).

      Even with SMP support, I don't think you get a really high degree of concurrency unless you have a threading implementation that involves the kernel.

      FreeBSD 4.x on a dual processor machine, for example, will take each process currently running, and assign it to a free CPU (either 0 or 1). This works great if you have more than one process running on your machine with a good division of labour (i.e. Apache + MySql).

      However, there are times when you want your box to be dedicated to a single purpose like being a datbase server only. That database engine might be a single process application like Oracle, and was written to break it's own internal tasks off into threads.

      A kernel thread implementation means you don't waste the second CPU of your SMP capable OS in this situation.

      Way to go NetBSD team, for implementing this. I hope I get to see this in action in 1.7

      --
      Success is as dangerous as failure, hope as hollow as fear.
    3. Re:Does this mean...? by orangesquid · · Score: 5, Funny

      What's more important, NetBSD can now support pcloth natively, which means pclothes! And soon, pfashion! They're well on their way to stardom... as soon as NetBSD/catwalk takes off, we'll start seeing ports to The Limited, The Gap, Sears, J. C. Penney's, and T. J. Maxx... Boy, I can't wait for NetBSD/hottopic---I'll about that daemon about metal spikes yet!

      In other news, Fig Leaf Linux Corp.'s stocks took a major dive, while Thimble+Needle Webhosting Co. skyrocketed. Red Hat Linux is holding steady, although this may change with conditions in the felt market.

      --
      --TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
    4. Re:Does this mean...? by hubertf · · Score: 3, Informative

      SMP means running processes on more than one CPU in parallel. (With some care-taking from the kernel that both CPUs don't step on each other WRT writing to kernel data structures etc.).

      Threading means splitting up a process into several (well :) threads, and let them run on either one or more than one CPU. This is basically an application-layer thing, in contrast to SMP which happens inside the kernel. Of course having SMP available helps for performance in threads systems as you can run threads in parallel on several CPUs, but SMP is not strictly necessary for a threaded system.

      Many applications today use a threaded software architecture (over the classical Unix "fork"ed processes), and so having some efficient threads implementation is very important.

      With the Scheduler Activations based work that Jason and Nathan made, this is a very efficient implementation as you can map N userland threads to M kernel threads, and you don't have one kernel thread for each userland thread, like some other systems (used to?) have, and which kills performance if you have many threads.

      - Hubert

    5. Re:Does this mean...? by Webmonger · · Score: 2, Informative

      All that's true, but when you have a multithreaded process, there's an efficiency loss if two threads from the same process are running on different CPUs. Since threads from the same process tend to access the same memory addresses, you don't get the normal advantages of CPU memory caching.

  2. Good news. by noselasd · · Score: 2, Informative

    Glad to see NetBSD is keeping up with the rest of the world.
    While (native)threading support has taken quite some time to come to NetBSD one
    can be assured that the implementation is done right, as always with NetBSD.