7

我在以下位置找到了以下自旋锁代码boost::smart_ptr：

bool try_lock()
{
    return (__sync_lock_test_and_set(&v_, 1) == 0);
}
void lock()
{    
    for (unsigned k=0; !try_lock(); ++k)
    {
        if (k<4)
            ; // spin
        else if (k < 16)
            __asm__ __volatile__("pause"); // was ("rep; nop" ::: "memory")
        else if (k < 32 || k & 1)
            sched_yield();
        else
        {
            struct timespec rqtp;
            rqtp.tv_sec  = 0;
            rqtp.tv_nsec = 100;
            nanosleep(&rqtp, 0);
        }
    }
}
void unlock()
{
     __sync_lock_release(&v_);
}

因此，如果我正确理解这一点，当锁被争用时，传入线程将呈指数级回退，首先疯狂旋转，然后暂停，然后产生其时间片的剩余部分，最后在睡眠和产生之间翻转。

我还找到了glibc pthread_spinlock实现，它使用程序集来执行锁定。

#define LOCK_PREFIX "lock;" // using an SMP machine

int pthread_spin_lock(pthread_spinlock_t *lock)
{
    __asm__ ("\n"
       "1:\t" LOCK_PREFIX "decl %0\n\t"
       "jne 2f\n\t"
       ".subsection 1\n\t"
       ".align 16\n"
       "2:\trep; nop\n\t"
       "cmpl $0, %0\n\t"
       "jg 1b\n\t"
       "jmp 2b\n\t"
       ".previous"
       : "=m" (*lock)
       : "m" (*lock));

    return 0;
}

我承认我对汇编的理解不是很好，所以我不完全理解这里发生了什么。（有人可以解释一下这是在做什么吗？）

但是，我对 boost spinlock 和 glibc pthread_spinlock 进行了一些测试，当内核多于线程时，boost 代码的性能优于 glibc 代码。

另一方面，当线程多于内核时，glibc 代码更好。

为什么是这样？这两个自旋锁实现之间有什么区别，使它们在每种情况下的表现都不同？

4

1 回答 1

5

您从哪里获得pthread_spin_lock()问题中发布的实施？它似乎缺少几条重要的线。

我看到的实现（不是内联汇编——它是来自 的独立汇编源文件glibc/nptl/sysdeps/i386/pthread_spin_lock.S）看起来很相似，但有两个额外的关键指令：

#include <lowlevellock.h>

    .globl  pthread_spin_lock
    .type   pthread_spin_lock,@function
    .align  16
pthread_spin_lock:
    mov 4(%esp), %eax
1:  LOCK
    decl    0(%eax)
    jne 2f
    xor %eax, %eax
    ret

    .align  16
2:  rep
    nop
    cmpl    $0, 0(%eax)
    jg  1b
    jmp 2b
    .size   pthread_spin_lock,.-pthread_spin_lock

它递减long传入参数所指向的 a 并在结果为零时返回。

否则，结果为非零，这意味着该线程没有获得锁。所以它执行 a rep nop，相当于pause指令。这是一个“特殊”nop，它向 CPU 提示线程处于自旋状态，并且 cpu 应该以某种方式处理内存排序和/或分支预测，以提高这些情况下的性能（我不假装准确了解芯片覆盖下发生的不同情况 - 从软件的角度来看，与普通的旧版本没有区别nop）。

在pause它再次检查该值之后 - 如果它大于零，则锁未被认领，因此它跳转到函数的顶部并尝试再次认领锁。否则，它会跳转到pause另一个。

这个自旋锁和 Boost 版本之间的主要区别在于，这个自旋锁在pause旋转时从不做任何比 a 更花哨的事情——没有什么比 asched_yield()或nanosleep(). 所以线程保持热。我不确定这在您提到的两种行为中是如何发挥作用的，但是 glibc 代码会更贪婪 - 如果一个线程在锁上旋转并且有其他线程准备运行但没有可用的核心，则旋转线程不会t 帮助等待线程获得任何 cpu 时间，而 Boost 版本最终会自愿为等待关注的线程让路。

于 2012-07-13T00:57:07.107 回答