码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2015-07-28 06:42:38      阅读:184      评论:0      收藏:0      [点我收藏+]

标签:

周日傍晚,我去家附近的超市(...)买苏打水,准备自制青柠苏打,我感觉我做的比买的那个巴黎水要更爽口。由于天气太热,很多人都去超市避暑去了,超市也不撵人,这仿佛是他们的策略,人过来避暑了,走的时候难免要买些东西的,就跟很多美女在公交地铁上看淘宝消磨时光,然后就下单了...这是多么容易一件事,反之开车的美女网购就少很多。对于超市的避暑者,要比公交车上下单更麻烦些,因为有一个成本问题,这就是排队成本。
       其实这是一个典型的多服务台排队问题,但是超市处理的并不好,存在队头拥塞问题,我就好几次遇到过。好几次,我排的那个队,前面结账出现了纠纷,我们后面的就必须等待,眼睁睁看着旁边的结账队伍向前推进,但是这种排队方案足够简单,把调度任务交给了排队者本人,结账的人想排到哪个队列就排到哪个队列,判断一个队列是否会拥塞也有很多办法,比如看购物的多少,是否有衣物(锁卡拔出纠纷),是否有称重的东西(会忘记称重),是否有打折物,是否有老年人,收银员的手法是否娴熟等,全靠自己的判断,无异于一场赌博。  我改造的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内核的排队自旋锁的实现很接近了。在此不谈优化,然而实际使用时,应该是先用汇编编码,然后汇编码优化它了。

版权声明:本文为博主原创文章,未经博主允许不得转载。

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

标签:

原文地址:http://blog.csdn.net/dog250/article/details/47098055

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!