本地自旋锁与信号量/多服务台自旋队列-spin wait风格的信号量

周日傍晚,我去家附近的超市(...)买苏打水,准备自制青柠苏打。我感觉我做的比买的那个巴黎水要更爽口。由于天气太热,非常多人都去超市避暑去了,超市也不撵人,这仿佛是他们的策略。人过来避暑了,走的时候难免要买些东西的。就跟非常多美女在公交地铁上看淘宝消磨时光,然后就下单了...这是多么easy一件事,反之开车的美女网购就少非常多。对于超市的避暑者,要比公交车上下单更麻烦些,由于有一个成本问题,这就是排队成本。
       其实这是一个典型的多服务台排队问题,可是超市处理的并不好。存在队头拥塞问题。我就好几次遇到过。好几次,我排的那个队。前面结账出现了纠纷。我们后面的就必须等待,眼睁睁看着旁边的结账队伍向前推进。可是这样的排队方案足够简单。把调度任务交给了排队者本人,结账的人想排到哪个队列就排到哪个队列,推断一个队列是否会拥塞也有非常多办法,比方看购物的多少。是否有衣物(锁卡拔出纠纷),是否有称重的东西(会忘记称重)。是否有打折物。是否有老年人。收银员的手法是否娴熟等。全靠自己的推断。无异于一场赌博。  我改造的OpenVPN多线程实现就是这样的。
       银行服务以及饭店的排队服务就要好非常多,顾客排队时。自取一个号码,排入单一的队列,由空暇服务台叫号。这就是一个调度系统。这样的单队列多服务台是不会出现队头拥塞的,等候的顾客持ticket排队。本身不必排在队伍里,而ticket号逻辑上组成一个虚拟的队列,没叫到号的能够临时干点别的,自身不必排队。

临时干别的?并不意味着你能够离开。特别是业务处理流程非常快的情况下。

你离开大厅。刚走出去。准备去旁边的小店逛逛,结果听到叫到你的号了,赶紧返回。其实还不如不出去呢。可是对于等待比較久的叫号系统,那倒是能够临时出去。出去再返回的过程意味着体力开销,可是如果出去的时间久,能够完毕另一件重要的事,意味着为这另外这件事的收益付出的体力开销是值得的。

知道我想到什么了吗?我想到了信号量。

信号量就是一个单队列多服务台排队系统,信号量的初始值就是服务台的数量。

一个运行流被服务意味着少了一个可服务的服务台。这就是down操作,而up操作则是一个服务台又一次变成空暇的信号,这意味着有一个新的排队者能够得到服务了,我能够把”服务“理解成进入临界区。

我在想一个问题,为什么信号量一定要设计成sleep-wait的模式,为什么就没有spin-wait的模式啊。而我眼下面临的问题,如果使用sleep-wait,切换开销太大,perf显示的头几名大头都在schedule,wake up。之类的,也就是说,你切换出去了,没多久就又把你叫回来了,好在Linux调度系统基于CFS全然公平机制,抖动不会太厉害。只是这么切换一次造成的开销也不算小。起码等到再次切换回来的时候。cache变凉了。

回想Linux版的ticket自旋锁。我认为全部的排队者以及持锁者touch同一个变量,该变量会cache到全部的当事者cpu的cache中,被持锁者以及争锁者read/write时,会涉及到多个处理器之间的cache一致性问题,这也是一笔非常大的底层开销。于是我设计了一个本地接力自旋锁改变了这个局面,保持每个争锁者都仅仅touch一个别的争锁者不会touch的变量。且cache line要着色以保证不会cache到同一line,此外,持锁者在释放锁的时候,仅仅会write下一个争锁者的本地变量。

这样就确保了cache一致性被最少的触发。
       本着这个新的自旋锁设计,结合我在超市的经历,我想把我这个自旋锁发展成一个能够有多个CPU持有锁的自旋队列。后来我突然发现,这不就是信号量嘛...可惜信号量并没有如期被我所用,由于Linux实现的信号量是sleep-wait机制的,我须要的是spin-wait,由于我知道一个数据包的发送是非常快的,之所以引入队列。构建VOQ,是由于我想避开N加速比问题,然而我的算法是软实现,根本不存在N加速比问题,所以后来我想取消VOQ,又怕引发队头拥塞。所以採用了多服务台单队列机制,为了实现这个,我本能够採用信号量的,可是又不想sleep,所以採用极其复杂的多个spin lock的机制,超市排队引发的遐想导致我想到用spin-wait来实现信号量,其实,简单測试之后。发现效果还真不错。

先看一下Linux原生的信号量实现。代码比較简单。顺便说一句。这篇文章并不意味着我又開始源码分析了,而是或许它意味着某种终结,前后的呼应。

/*
 * 为了突出重点问题,不至于迷失在代码细节.我做了下面的如果:
 * 1.我省去了操作信号量本身的自旋锁,我如果P/V操作过程的随意序列都是原子的.
 * 2.我取消了超时參数以及state,我如果除非得到信号量,否则一定等下去,我还如果睡眠不会被打断,除非有人唤醒.
 * 3.我取消了inline,由于我想突出环绕本地栈变量本地自旋,这样不会cache pingpong.
 */
struct semaphore {
    raw_spinlock_t        lock;
    unsigned int        count;
    struct list_head    wait_list;
};

struct semaphore_waiter {
    struct list_head list;
    struct task_struct *task;
    // 本地局部检測变量
    bool up;
};

static int down(struct semaphore *sem)
{
    if (likely(sem->count > 0)) {
        sem->count--;
    }
    else {
        struct task_struct *task = current;
        struct semaphore_waiter waiter;
        // 栈上的排队体,相当于ticket,获得信号量(函数返回)后就没实用了
        list_add_tail(&waiter.list, &sem->wait_list);
        waiter.task = task;
        waiter.up = false;

        for (;;) {
            __set_task_state(task, TASK_UNINTERRUPTIBLE);
            schedule();

            // 本地栈变量的检測,降低了多处理器之间的cache同步。不会cache乒乓
            // ********************************************************************
            // 可是要想到一种情况。如果多个进程试图写这个变量,还是要有锁操作的。

// 尽管我的如果是全部操作以及操作序列都是原子的,可是在up操作中。持有信
            // 号量的进程仅仅是简单的wake up了队列,而这并不能确保被唤醒的task就一定可
            // 以得到运行,中间另一个schedule层呢。鉴于这样的复杂的局面,我想到了不
            // sleep,而是本地自旋版本号的信号量。无论如何,它确实攻克了我的问题。

// [其实,由于sem本身拥有一把自旋锁,这就禁止了多个“服务台”同一时候召唤
            //  同一个等待者的局面,而我在我的描写叙述中,忽略了这把自旋锁,这是为什么呢?
            //  由于。我想为我的自旋信号量版本号贴金,不然人家都把问题攻克了,我还扯啥
            //  玩意儿啊!]
            // ********************************************************************
            // 这样的情况在spin lock下不会存在,由于同一时候仅仅有一个进程会持有lock,
            // 不可能多个进程同一时候操作。

if (waiter.up) {
                return 0;
            }
        }
    }
}

void up(struct semaphore *sem)
{
    unsigned long flags;
    if (likely(list_empty(&sem->wait_list))) {
        sem->count++;
    } else {
        struct semaphore_waiter *waiter = list_first_entry(&sem->wait_list,
                            struct semaphore_waiter, list);
        // 标准的Linux kernel中。该操作被spin lock保护,这意味着不可能多个服务台同一时候将
        // 服务给与同一个等待者。
        list_del(&waiter->list);
        waiter->up = true;
        // 简单wake up进程。它何时投入运行,看调度器何时调度它了。
        wake_up_process(waiter->task);
    }
}

由于我忽略了信号量本身的保护自旋锁,当你具体分析上述实现的时候。会发现非常多竞争条件,比方同一时候多个服务台召唤一个等待者,可是没关系,该说的我都写到冗长的凝视里面了。

我之所以忽略信号量的自旋锁,是由于我想把信号量该造成一个通用的自旋等待队列,自旋锁仅仅是当中一个特殊情况,该情况相应仅仅有一个服务台的情形。
       如果看懂了原生的实现,那么改造后的实现应该是下面的样子:

?/*
 * 我引入了BEGIN_ATOMIC和END_ATOMIC两个宏。由于我不想贴汇编码。所以这两个宏的意思就是它们之间的代码都是由
 * lock前缀修饰的,锁总线。

* 此外,什么事情都没有做。仅仅是改了名称。如果想初始化一个标准的排队自旋锁,将初始化宏的val设置成1就可以。
 */
struct spin_semaphore {
    unsigned int        count;
    struct list_head    wait_list;
};

struct spin_semaphore_waiter {
    struct list_head list;
    struct task_struct *task;
    // 本地局部检測变量
    bool up;
};

static int spin_down(struct spin_semaphore *sem)
{
    if (likely(sem->count > 0)) {
        sem->count--;
    }
    else {
        struct task_struct *task = current;
        struct spin_semaphore_waiter waiter;
BEGIN_ATOMIC
        list_add_tail(&waiter.list, &sem->wait_list);
        waiter.task = task;
        waiter.up = false;
END_ATOMIC

        for (;;) {
            cpu_relax();  // PAUSE
            if (waiter.up) {
                return 0;
            }
        }
    }
}

void up(struct spin_semaphore *sem)
{
    unsigned long flags;
BEGIN_ATOMIC
    if (likely(list_empty(&sem->wait_list))) {
        sem->count++;
END_ATOMIC
    }
    else {
        struct spin_semaphore_waiter *waiter = list_first_entry(&sem->wait_list,
                            struct spin_semaphore_waiter, list);
        list_del(&waiter->list);
        waiter->up = true;
END_ATOMIC
    }
}

全部名称加上了spin_前缀修饰。不错。这个应该是和Windows NT内核的排队自旋锁的实现非常接近了。在此不谈优化。然而实际使用时,应该是先用汇编编码。然后汇编码优化它了。

时间: 2024-10-13 19:33:18

本地自旋锁与信号量/多服务台自旋队列-spin wait风格的信号量的相关文章

信号量、互斥体和自旋锁

http://www.cnblogs.com/biyeymyhjob/archive/2012/07/21/2602015.html 信号量.互斥体和自旋锁 一.信号量 信号量又称为信号灯,它是用来协调不同进程间的数据对象的,而最主要的应用是共享内存方式的进程间通信.本质上,信号量是一个计数器,它用来记录对某个资源(如共享内存)的存取状况.一般说来,为了获得共享资源,进程需要执行下列操作:  (1) 测试控制该资源的信号量.  (2) 若此信号量的值为正,则允许进行使用该资源.进程将信号量减1.

linux 自旋锁和信号量【转】

转自:http://blog.csdn.net/xu_guo/article/details/6072823 版权声明:本文为博主原创文章,未经博主允许不得转载. 自旋锁最多只能被一个可执行线程持有(读写自旋锁除外).自旋锁不会引起调用者睡眠,如果一个执行线程试图获得一个已经被持有的自旋锁,那么线程就会一直进行忙循环,一直等待下去(一直占用 CPU ),在那里看是否该自旋锁的保持者已经释放了锁, " 自旋 " 一词就是因此而得名. 由于自旋锁使用者一般保持锁时间非常短,因此选择自旋而不

linux 自旋锁和信号量

自旋锁最多只能被一个可执行线程持有(读写自旋锁除外).自旋锁不会引起调用者睡眠,如果一个执行线程试图获得一个已经被持有的自旋锁,那么线程就会一直进行忙循环,一直等待下去(一直占用 CPU ),在那里看是否该自旋锁的保持者已经释放了锁, " 自旋 " 一词就是因此而得名. 由于自旋锁使用者一般保持锁时间非常短,因此选择自旋而不是睡眠是非常必要的,自旋锁的效率远高于互斥锁. 信号量和读写信号量适合于保持时间较长的情况,它们会导致调用者睡眠,因此只能在进程上下文使用(因为中断的上下文不允许休

信号量、互斥体和自旋锁小结

概述 linuxn内核同步机制几种常用的方式,面试经常会被问道,这里做一个小结 [1]信号量 [2]互斥体 [3]自旋锁 [4]区别 1.信号量(semaphore) 又称为信号灯,本质上,信号量是一个计数器,用来记录对某个共享资源的存取情况,一般共享资源通过以下步骤 (1) 测试控制该资源的信号量(n). (2) 若此信号量的值为正,则允许进行使用该资源.进程将信号量减1. (3) 若此信号量为0,则该资源目前不可用,进程进入睡眠状态,直至信号量值大于0,进程被唤醒,转入步骤(1). (4)

Linux 同步方法剖析--内核原子,自旋锁和互斥锁

在学习 Linux® 的过程中,您也许接触过并发(concurrency).临界段(critical section)和锁定,但是如何在内核中使用这些概念呢?本文讨论了 2.6 版内核中可用的锁定机制,包括原子运算符(atomic operator).自旋锁(spinlock).读/写锁(reader/writer lock)和内核信号量(kernel semaphore). 本文还探讨了每种机制最适合应用到哪些地方,以构建安全高效的内核代码. 本文讨论了 Linux 内核中可用的大量同步或锁定

【转】自旋锁及其衍生锁

原文网址:http://blog.chinaunix.net/uid-26126915-id-3032644.html 自旋锁 自旋锁(spinlock)是用在多个CPU系统中的锁机制,当一个CPU正访问自旋锁保护的临界区时,临界区将被锁上,其他需要访问此临界区的CPU只能忙等待,直到前面的CPU已访问完临界区,将临界区开锁.自旋锁上锁后让等待线程进行忙等待而不是睡眠阻塞,而信号量是让等待线程睡眠阻塞.自旋锁的忙等待浪费了处理器的时间,但时间通常很短,在1毫秒以下. 自旋锁用于多个CPU系统中,

多线程编程之自旋锁

一.什么是自旋锁 一直以为自旋锁也是用于多线程互斥的一种锁,原来不是! 自旋锁是专为防止多处理器并发(实现保护共享资源)而引入的一种锁机制.自旋锁与互斥锁比较类似,它们都是为了解决对某项资源的互斥使用.无论是互斥锁,还是自旋锁,在任何时刻,最多只能有一个保持者,也就说,在任何时刻最多只能有一个执行单元获得锁.但是两者在调度机制上略有不同.对于互斥锁,如果资源已经被占用,资源申请者只能进入睡眠状态.但是自旋锁不会引起调用者睡眠,如果自旋锁已经被别的执行单元保持,调用者就一直循环在那里看是否该自旋锁

zbb20180929 thread 自旋锁、阻塞锁、可重入锁、悲观锁、乐观锁、读写锁、对象锁和类锁

1.自旋锁自旋锁可以使线程在没有取得锁的时候,不被挂起,而转去执行一个空循环,(即所谓的自旋,就是自己执行空循环),若在若干个空循环后,线程如果可以获得锁,则继续执行.若线程依然不能获得锁,才会被挂起.使用自旋锁后,线程被挂起的几率相对减少,线程执行的连贯性相对加强.因此,对于那些锁竞争不是很激烈,锁占用时间很短的并发线程,具有一定的积极意义,但对于锁竞争激烈,单线程锁占用很长时间的并发程序,自旋锁在自旋等待后,往往毅然无法获得对应的锁,不仅仅白白浪费了CPU时间,最终还是免不了被挂起的操作 ,

Linux设备驱动程序 之 自旋锁

概念 自旋锁可以再不能休眠的代码中使用,比如中断处理例程:在正确使用的情况下,自旋锁通常可以提供比信号量更高的性能: 一个自旋锁是一个互斥设备,它只能由两个值,锁定和解锁:通常实现为某个整数值中的单个位:希望获得特定锁的代码测试相关位,如果锁可用,则锁定位被设置,而嗲吗继续进入临界区:相反,如果锁被其他人获得,则代码进入忙循环并重复检查这个锁,直到该锁可用为止:这循环就是自旋锁自旋的部分: 自旋锁在不同的架构上实现有所不同,但是核心概念低于所有系统都都是一样的,当存在某个自旋锁时,等待执行忙循环