Slashdot Mirror


Next Generation POSIX Threading Version 1.9.0

axehind writes "IBM announced release 1.9.0 of NGPT (Next Generation POSIX Threading). The goal of this project is to attempt to solve the problems associated with the use of the pthreads library on Linux and improve significantly on the POSIX compliance of pthreads on Linux. It's licensed under the LGPL and can be downloaded here."

15 comments

  1. Next Generation POSIX Threading by Anonymous Coward · · Score: 1, Informative

    NGPT Release 1.9.0 is the first "unstable" release of the NGPT 2.0 development tree. This release
    is fully suitable as a replacement for LinuxThreads by either a single user or group or and entire
    distribution. The NGPT team plans to do releases almost weekly of this 1.9.x tree until the release
    of NGPT 2.0.

    In this release, we've concentrated on primarily on a single area, shared mutexes. NGPT mutex operations
    now respect the pshared option. Please note, however, this is very early code and could cause you
    some problems.

    The binary RPMs supplied with this release are based on and built for use with a 2.4.19pre8 or better
    kernel that has the new "officially" sanctioned support for NGPT. In addition it is necessary for
    you to apply the new patch-futex-2.4.19-pre8 patch, included in this release. This patch is based on
    new functionality already provided in the 2.5 kernel that will eventually be backported to the 2.4
    kernel and support. NGPT takes advantage of the functionality provided by this patch to efficiently
    handle mutexes, both shared and non-shared. This patch is **ABSOLUTELY REQUIRED**. NGPT will not
    function without it. The installation instructions have changed a bit as well and you should
    check the INSTALL file for the updated instructions.

    You can build the library from source by downloading the source tarball or source rpm and
    consulting the INSTALL file.

    If you are running with a 2.5.x experimental kernel, it's best that run with 2.5.20 or higher since
    it will already have the required changes for NGPT. You will also have to rebuild NGPT from either
    the source tarball or rpm.

    As an UNSTABLE RELEASE, this release is not suitable for use in a production environment, however, it
    should be noted that we have done fairly extensive testing and you should find this release relatively
    free of problems. If you encounter any problems with this release please post them to the NGPT website
    and the development team will address them.

    Known Problems
    ==============
    1. In LinuxThreads, credentials are thread based. In NGPT running on a uniprocessor machine,
    credentials are process based as demanded by POSIX. However, on an SMP machine, this is
    not yet true.

    2. This release will work only on IA32 (x86), IA64, PowerPC and S/390 architectures. We're
    always looking for folks with specific platform experience to port NGPT to additional
    hardware platforms.

    3. There is currently no built-in support in gdb for debugging NGPT based applications. However,
    to debug a program linked with NGPT you can set the environment variable MAXNATIVETHREAD=1 to
    disable M:N threading making it relatively simple to use the standard issue gdb.

    4. NGPT has only been tested with 2.5.20 or higher of the experimental kernels.

    1. Re:Next Generation POSIX Threading by Anonymous Coward · · Score: 0

      Thank you for posting the release notes that are linked to. It was very insightful and informative, since IBM tends to get Slashdotted NEVER. Fucktard.

    2. Re:Next Generation POSIX Threading by Anonymous Coward · · Score: 0

      AC, You may not have noticed that the post is actually a well crafted Troll - beautiful in its
      scripted subtlty.

      As always, if you work for Slashdot and your
      name is fuckwad Timothy, FUCK YOU in
      both eyes. Pray that I never meet you in a
      dark alley, BITCH.

      - Penguin Kicka

  2. RE: Mirror Please by tenman · · Score: 0, Troll

    You can find a mirror Here.

  3. Humorous by selectspec · · Score: 2
    ...It will also enable Linux to provide threading services that are more in line with the capabilities of the commerical Unix operating system such as IBM AIX and SGI IRIX.

    Cough - no mention of sun threads (Solaris).

    --

    Someone you trust is one of us.

    1. Re:Humorous by morbid · · Score: 0

      Sun threads are what POSIX threads are based on.
      It's funny how everyone is looking forward to this M:N threading model, when it has been shown in the field to be a hinderance rather than a help. 1:1 threading is simpler, more efficient and provides much better over-all performance.

      --
      I'm out of my tree just now but please feel free to leave a banana.
    2. Re:Humorous by chez69 · · Score: 0

      except when the system has *lots* of threads running at once. then the overhead of managing the large amounts of threads gets in the way.

      --
      PHP is the solution of choice for relaying mysql errors to web users.
    3. Re:Humorous by shani · · Score: 2

      From Solaris 2.5 to Solaris 8, POSIX threads on Solaris have been built on Sun threads. My understanding is that with Solaris 9, Sun has finally decided that POSIX threads are here to stay, and built their Sun threads on top of POSIX threads.

    4. Re:Humorous by JKR · · Score: 1
      Cough - no mention of sun threads (Solaris)

      The fact that Sun called their threads "Light Weight Processes" might give you a clue why that might be ;-)

      "No, you can't just call fork() and pretend it's a thread!"

      Jon.

    5. Re:Humorous by Anonymous Coward · · Score: 0

      They've also decided that for most purposes 1:1 threading model is more efficient. That's why it's the default on Solaris 9. The other stuff is provided as well.

    6. Re:Humorous by Anonymous Coward · · Score: 0

      Solaris threads suck.
      Have they fixed the dozens of thread bugs yet?

  4. Very nice, but how does it actually help? by not-him-again · · Score: 1
    It provides process-shared mutexes under Linux -- but we can already do that with spin-locks.

    What about process-shared semaphores in shared memory? There's no mention of those in change log or release notes. You could fake semaphores with spin-locks (and lots of spinning) or use SysV semaphores. So that hasn't changed.

    Support for dual-CPU boxes? Not yet, apparently.

    The NGPT folks had initially thought that they'd make the PTHREAD_PROCESS_SHARED attribute available almost a year ago, so, if you can hack this stuff, and have time, please help them!

    --
    Suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself. -- Mark Twain.