和dede聊OS

         dede提出了一个用互斥量（Mutex）模拟信号量（Semaphore）的课题，非常有趣。
　　dede提出应该这样，用i作为状态标识：
    lock(i_m);
    if (i > 0) {
        i--;
        unlock(i_m);
        enter_critical_region();
        lock(i_m);
        i++;
        unlock(i_m);
    } else {
        unlock(i_m);
        lock(m);
        enter_critical_region();
        unlock(m);
    }
　 　如果没有理解错，信号量用于限制可同时进入关键区域的线程个数，而i也起到这个目的。那么当线程陆续创建并陆续退出的时候（在一定时间后，线程数目保持 在多于关键区域可接受线程个数），那么会不会造成计数的问题呢？在上半条件分支里的关键区域执行完毕后并不会开启锁。而当有线程被挂起在下半分支的时候， 如果上半分支的线程推到一定程度，则上半分支打开，以后进来的线程都在上半分支运行，于是下半分支的线程就饿死了。
　　根据dede的思路，我一开始这样写：
    lock(i_m);
    if (i > 0)
    {
        i--;
        unlock(i_m);
        enter_critical_region();
    }
    else
    {
        i--;
        unlock(i_m);
        lock(m);
        enter_critical_region();
        unlock(m);
    }
    lock(i_m);
    i++;
    unlock(i_m);
　　然后，仔细查看了一下发现也不对。因为这仍旧没有解决下半分支线程饿死的可能。于是考虑在上半部分线程执行完毕后也应当开锁（开着的锁再开一次则忽略），因为线程数的最大情况是在达到线程容限时，只要有线程退出，就允许有线程进入。于是写了下面的代码：
    lock(i_m);
    if (--i < 0)
    {
        lock(m);
    }
    unlock(i_m);
    enter_critical_region();
    lock(i_m);
    i++;
    unlock(i_m);
    unlock(m);
　　这个代码的正确性也需要验证。然而这样的替代应该还是不能算完全的，因为信号量主要在生产者/消费者模型中使用，替代代码显然无法对对方的行为做出反应。如果要做出反应可能就需要循环，这样就陷入dede前一封信中提到的spin lock问题。
　　以上想法并不成熟，随时补完。

BEA Tuexdo系统快速入门（三）－－服务端开发：【上一篇】
ubuntu GNOME下完美编译安装EVA（绝对详细）：【下一篇】