读《时间管理 - 给系统管理员》

本书第一章节有个问题是说：如何构建一个共同抗干扰防线。

现在讨论这个问题：

从程序员的角度，我认为每个组都可以认为是一个类，每个组员都是其中的一个成员变量或者是成员函数。更贴切的如果把人比做是函数，那组内的资源就可以认为是变量。每个组都有其职能，他要为其他的类提供服务，其提供的接口，以及其应用实例就阐明了一个服务的流程。作为一个组员，我希望我对应的这个函数是私有的，尽量少的开放给外界来访问。我工作的内容越少，服务的对象越单一，那么我被中断的概率就会越低，这样老板必定不会同意，所以我觉得应该将服务尽可能的抽象并加以简化。比如硬件找我烧板子，我应该将环境保留好，并保留操作的文档和记录，必要的话可以编写脚本。将这个过程抽象就是规范化操作流程，将多次操作的共用部分提取出来，用硬件加速器，或协处理器来完成（可以理解成不太需要个人干预的，如用工具或软件来实现）。

上面说的这个例子只是讲如何编写中断处理程序，使得他运行更有效率。而减少在中断中陷入的时间。但是这不是这个问题的核心，为什么这么说呢？其实有些悲哀，在实际中你会发现当你工作效率越高的时候就会有越多的任务会划分你做，就像是一个沙漏，流得快，必定单位时间内就流的多。重点还是如何减少被中断的次数。我觉得根本上这个被中断的次数是由系统结构设计决定的，例如部门内部的组织结构以及职责划分。我们没有秘书和助理，实际上没有太好的办法来阻止被别人中断，即使不在公司，电话一样会打到我的手机上。而且职位越高，接触的面就越多，负责的事情越多，被中断的次数也就越多。
1. 我觉得有个好办法就是定义出规范的流程，然后公事公办。就像是路由器的转包算法，他查的那个路由表就是前面说的这个所谓的规范。我们没有那么厉害也没有那么伟大可以在工位上挂个牌子写着所有事情到我这里结束这样的话。
2. 可以区分中断类型，对于高频出现的，处理简单的中断，专门提供出资源来处理。
3. 还有个办法是来自于Linux的内核设计的思想，就所谓的bottom half结构，中断来了我只是做些必要的记录并不立刻产生任务切换，比如我回个邮件说我知道了，等等去看之类的话。

我的理解：真正的减少中断还在于硬件的结构，你一定会被中断，除非你关闭这个中断源。所以我把更多的描述放在了中断出现的处理策略中。

我打算在后面的工作中使用RR的任务调度方式，而且是不可剥夺的。这样的话我需要定义好这个时间片的长度，我需要知道当我集中精力做某事的时候可以持续多少时间！