pthread spinlocks on uniprocessor machines. - Unix

This is a discussion on pthread spinlocks on uniprocessor machines. - Unix ; I don't have a uniprocessor machine to test this on. Can I safely use a pthread spin lock (e.g. pthread_spin_init) on a uniprocessor machine without making it grind to a halt? Does pthreads do some magic and implement it as, ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: pthread spinlocks on uniprocessor machines.

  1. pthread spinlocks on uniprocessor machines.

    I don't have a uniprocessor machine to test this on.

    Can I safely use a pthread spin lock (e.g. pthread_spin_init) on a
    uniprocessor machine without making it grind to a halt? Does pthreads
    do some magic and implement it as, say, a "regular" mutex on single-
    core machines? Or do I need to have separate application builds for
    single and multi-core platforms?

    Thanks,
    Jason

  2. Re: pthread spinlocks on uniprocessor machines.

    On Sep 22, 12:08*pm, Jason C wrote:

    > Can I safely use a pthread spin lock (e.g. pthread_spin_init) on a
    > uniprocessor machine without making it grind to a halt?


    Yes.

    > Does pthreads
    > do some magic and implement it as, say, a "regular" mutex on single-
    > core machines? Or do I need to have separate application builds for
    > single and multi-core platforms?


    If the system threading library does something incredibly bone-headed,
    you may be forced to work around it. But I wouldn't assume it's going
    to do something incredibly stupid just for the hell of it.

    The standard does not define what it means for a spinlock to "spin"
    other than to say that the pthread_spin_lock function must not return
    until it acquires the lock or detects an error. The use of a spin lock
    rather than a mutex is a hint to the implementation that you would
    expect spinning to be faster than a context switch. The implementation
    is free to ignore you if it knows you are wrong, and all sane
    implementations do so.

    DS

  3. Re: pthread spinlocks on uniprocessor machines.

    On Sep 22, 5:44*pm, David Schwartz wrote:
    > On Sep 22, 12:08*pm, Jason C wrote:
    >
    > > Can I safely use a pthread spin lock (e.g. pthread_spin_init) on a
    > > uniprocessor machine without making it grind to a halt?

    >
    > Yes.
    >
    > > Does pthreads
    > > do some magic and implement it as, say, a "regular" mutex on single-
    > > core machines? Or do I need to have separate application builds for
    > > single and multi-core platforms?

    >
    > If the system threading library does something incredibly bone-headed,
    > you may be forced to work around it. But I wouldn't assume it's going
    > to do something incredibly stupid just for the hell of it.
    >
    > The standard does not define what it means for a spinlock to "spin"
    > other than to say that the pthread_spin_lock function must not return
    > until it acquires the lock or detects an error. The use of a spin lock
    > rather than a mutex is a hint to the implementation that you would
    > expect spinning to be faster than a context switch. The implementation
    > is free to ignore you if it knows you are wrong, and all sane
    > implementations do so.


    Great, thanks for the quick answer and explanation!

    Jason


  4. Re: pthread spinlocks on uniprocessor machines.

    Jason C writes:
    > I don't have a uniprocessor machine to test this on.
    >
    > Can I safely use a pthread spin lock (e.g. pthread_spin_init) on a
    > uniprocessor machine without making it grind to a halt?


    Certainly. At worst, the thread will busy-wait until it has exhausted
    its time quantum.

    > Does pthreads do some magic and implement it as, say, a "regular"
    > mutex on single-core machines?


    The i386-NPTL-implementation indeed does: When compiled for UP, it
    doesn't lock the bus while spinning :->. IIRC, the QNX implementation
    silently ignores your request and always uses an ordinary mutex.

    The bottom line is that some interfaces refering to 'spin locks' have
    been standardized, but without defining what precisely constitutes a
    'spin lock'. Which means that you will have to check each
    implementation you intend to support what exactly is called a spin
    lock there or in other words, that there is no portable way to use
    spin locks (here referring to the MP synchronization primitive).
    Especially, an implementation is completely free to actually provide
    spin locks without caring if you know what that is.



  5. Re: pthread spinlocks on uniprocessor machines.

    On Sep 23, 8:46 am, Rainer Weikusat wrote:
    > Jason C writes:
    > > I don't have a uniprocessor machine to test this on.


    > > Can I safely use a pthread spin lock (e.g.
    > > pthread_spin_init) on a uniprocessor machine without making
    > > it grind to a halt?


    > Certainly. At worst, the thread will busy-wait until it has
    > exhausted its time quantum.


    Or longer, depending on the scheduling algorithm being used. If
    the system supports real-time scheduling, there will be
    scheduling policies where a lower priority thread will never
    replace a higher priority one.

    --
    James Kanze (GABI Software) email:james.kanze@gmail.com
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

+ Reply to Thread