我不是知识管理领域的专家，但我认为知识的积累和管理对一个期望长久稳定发展的组织来说很重要。今天我这个"门外人"就来说几句"门外话"。

我所在的部门已经成立10余年了，但说实话部门在知识积累和管理方面做的比较一般。例如，没有统一的知识积累和管理平台，知识分享多靠mail列表，或将知识存储在文件中放入Microsoft Visual SourceSafe，若干日子后，再无人能找到之前的知识(VSS绝对不是一个知识管理平台，顶多就是一个版本管理工具，还是个有些落伍的工具)；没有专人负责知识积累和管理；知识积累与管理似乎始终是优先级最低的那个任务。

近些年随着公司层面加强了对知识积累和管理的重视度，部门似乎也认识到了知识"丢失"现象的严重性，遂加强了知识积累方面的投入，但始终没有系统的知识积累和管理方案出台，部门内部依旧没有形成很好的知识积累的习惯。知识"丢失"不免让人痛心，于是今年年初我们决定自己在产品线内部搭建知识积累平台(采用MediaWiki)，并指派专人负责知识库建设、策划、知识整理以及知识库的备份(自动备份)。就这样我们"摸着石头过河"，一年下来收获颇丰。这里的收获指的不仅仅是积累的知识，还有宝贵的知识积累和管理的实践经验，更重要的是通过实践让我们更加认识到知识积累和管理的重要性，特别是对一个中等规模的组织而言。

我们的知识管理大致分为以下几个阶段。
一、知识库平台的建设
要想做知识积累和管理，首先要搭建一个知识管理的平台 – 知识库系统。组织内部的知识是由组织内部的人员协同生产出来的，除非你的组织需要特别专业的知识库管理平台以及特定的知识管理咨询服务，否则很多开源的Wiki工具可作为知识库的候选，比如TWiki、MediaWiki等。MediaWiki大家一定不陌生，因为世界上最大的知识库 - 维基百科(wikipedia)就是基于该工具搭建的，另外MediaWiki插件众多，也便于实现一些特定的需求。我们最终选择的也是MediaWiki。我这里倒没有什么选型的标准，只是觉得一款合格的知识库工具至少应具备一下几个特点：
- 访问方便，便于知识积累(例如，MediaWiki通过Browser访问，无需客户端装任何插件)
- 支持快速发现知识(例如，MediaWiki支持分类，标签，支持全文搜索，支持主题订阅)
- 适于协同创作，知识修改容易(这个本身就是Wiki的强项)
- 功能易扩展(例如，MediaWiki通过插件实现各种各样的功能，比如甘特图，日历)
- 知识展示手段丰富(例如，MediaWiki支持富文本，支持图片，内部和外部超链接等)

二、知识库结构策划阶段
每个组织都有自己特定的知识领域。知识库积累的就是在该领域内知识。积累前需要投入专人或小组来策划知识库的结构。将预想到的知识分门别类。分类由粗到细，甚至可以设置多级分类。为了便于知识发现，最好初始设定好一些常用的标签，这样通过搜索，我们就可以快速定位到知识所在。另外知识库的结构不是一成不变的，它应该随着知识库积累的知识的变化而适当变化，必要时需对知识库的结构做重构（比如发现之前的分类不合理）。知识库结构的重构带来的工作量有时候是很大的，所以尽量在初始情况下就全面合理地做好分类，避免后续重构。

三、知识积累阶段
知识库平台建立完毕后，就到了知识积累的阶段了，这个是全员参与的阶段。组织中的每个人都是知识库的贡献者。但事前最好制定一些知识积累的简要规程，比如规范知识提交的格式，规范主题的命名，段落格式等。知识积累阶段其实才是知识管理中最难的一个阶段，关键难在如何让组织内成员养成积极主动的进行知识积累的习惯，下面是一些可供参考的方法。

a) 适当宣导，让组织内成员意识到知识积累的重要性
b) 针对知识库平台的使用做适当的培训和交流
c) 将知识库平台打造的尽量易用，避免因复杂而导致排斥行为
d) 日常沟通多引用知识库中知识的位置，让大家在潜移默化中对知识库产生依赖

e) 引导关注。如果一个人贡献的知识受到大家的广泛关注，那么这个人将会有更大的热情贡献知识。组织内知识管理负责人可定期整理新增精品知识的简要并发给大家，吸引大家阅读知识，关注知识；通过展示知识关注度排名也可以激发大家的知识分享热情。

f) 发掘和鼓励"知识分享达人"。由"二八定律"我们可以推断，组织内20%的人贡献了80%的知识。我们要发掘出这些"达人"，给予鼓励，必要时给予一定奖励。
g) 将之前组织积累的以文件形式存在的知识迁移到新平台上。尽量将内容Web化而不是以文件附件（不利于知识发现）形式存在；如果没有精力，可对知识做简要描述，建立文件位置索引，方便大家发现。并鼓励大家在知识库平台上查找以前积累的知识。

四、知识整理
由于知识库是组织内人员协同丰富的，新知识的提交带有一定随意性，点状分布，不成系统，所以这些知识需要专人定期整理，划入适当分类，赋予更加合理的标签，尽量使其系统化。这个工作十分必要，否则一旦长久，知识库内的知识就像一根根独木，独自生长，永远也成不了连片的树林。

五、知识备份
知识是宝贵的，大家花了心血贡献的知识要保存好，保存完整。这样就需要定期对知识库进行备份。一般可通过后台运行的脚本自动备份，粒度做到每天备份一次自然就最好了。

六、做好知识在不同层次知识库的流动
不同组织知识库的建设是不同的，有的组织采用统一的知识库，有些组织有不同层次的知识库。对于前者，没有什么可说的，大家的知识都会汇集到一个库中；对于后者，我们需要弄清楚知识库的层次，让知识合理地在不同层次的知识库间流动。一般而言，低级别知识库(如部门的知识库）会定期将精华的且适合在上一级组织(公司的知识库)分享的知识导入上一级别知识库，换句话说低级别知识库可作为高级别知识库的素材库。

关于我们的知识管理实践大致就这么六点内容，我们现阶段也是这么做的。后续我们要想在知识管理这块有所进阶，估计是需要请知识管理专家授业解惑了。

restrict关键字是C99标准中新引入的一个类型修饰符(type qualifier)。如果你看过GNU C库的源码或是其manual，你就会发现restrict修饰符被广泛地应用在GNU C库中。restrict关键字到底是用来做什么的呢？估计很多对C语言细节研究不够的程序员都无法给出答案，我个人也只是停留在"知道"这一关键字的层次上，于是乎今天我又对着C99规范钻研了一番，略有收获，这里也说道说道。

为何C标准委员会要在C99标准中引入restrict呢？这当然是有历史原因的。我们先来看看下面这个例子：
/* foo.c */
void foo(int *p, int *q, int *r) {
    *p += *r;
    *q += *r ;
}

int main() {
    int a = 1;
    int b = 2;
    int c = 3;
    foo(&a, &b, &c);
}

C语言的设计哲学之一就是性能至上，为了性能可以舍弃一切。C程序员都希望编译器能为自己编写的程序生成高性能的目标代码，我们现在就来看看GCC编译器(在优化开关-O2已打开的情况下)为这段程序生成的目标代码是什么样子的。

我们通过GDB对函数foo进行反汇编，结果如下：

(gdb) disas foo
Dump of assembler code for function foo:
   0x080483c0 :    push   %ebp
   0x080483c1 :    mov    %esp,%ebp
   0x080483c3 :    mov    0×10(%ebp),%edx 
   0x080483c6 :    mov    0×8(%ebp),%ecx  
   0x080483c9 :    mov    0xc(%ebp),%eax  
   0x080483cc :    push   %ebx
   0x080483cd :    mov    (%edx),%ebx 
   0x080483cf :    add    %ebx,(%ecx) 
   0x080483d1 :    mov    (%edx),%edx 
   0x080483d3 :    add    %edx,(%eax) 
   0x080483d5 :    pop    %ebx
   0x080483d6 :    pop    %ebp
   0x080483d7 :    ret   
End of assembler dump.

这段汇编代码不是很难，我们将关键部分抽取出来并在每行汇编码后面给出解释：
mov    0×10(%ebp),%edx  ; r -> %edx，将指针r指向的内存对象的地址放入寄存器edx
mov    0×8(%ebp),%ecx   ; p -> %ecx，将指针p指向的内存对象的地址放入寄存器ecx
mov    0xc(%ebp),%eax   ; q -> %eax，将指针q指向的内存对象的地址放入寄存器eax
push   %ebx
mov    (%edx),%ebx  ; *r -> %ebx，将指针r指向的内存对象的值加载到寄存器ebx中
add    %ebx,(%ecx)  ; *r + *p -> *p， 将寄存器ebx中的数值与指针p所指内存对象的值相加，结果存放在指针p所指的内存对象中
mov    (%edx),%edx  ; *r -> %edx，将指针r指向的内存对象的值加载到寄存器edx中
add    %edx,(%eax)  ; *r + *q -> *q，将寄存器edx中的数值与指针q所指内存对象的值相加，结果存放在指针q所指的内存对象中

这段汇编代码是否是经过优化过的呢？我们结合foo函数的源代码分析后可以发现生成的目标码并非是经过优化的。在foo函数中指针r指向的内存对象一直都作为右值，其值没有被改动，编译器在第二次加法操作中完全可以直接利用第一次加载*r值的寄存器，而不是重新从内存中加载*r。但编译器为何没有优化掉这次访存操作呢？原因就在于编译器凭借C源代码中已有的信息是无法作出这种优化决策的。因为当编译器在foo的实现的上下文中看到三个指针时，它并不能判断出这三个指针所指向的地址是否有重叠，也就是说编译器并不能确定在第二次加法操作之前，r指向的内存对象是否被改变，编译器只能中规中矩地生成未经优化的目标代码，即每次都重新加载*r到寄存器，否则擅自优化会导致一些不可预期的行为。

那如何能帮助编译器作出正确的优化决策呢？这就需要程序员显式地为编译器提供用于决策的信息。在C99以前，很多编译器通过提供#Pragma参数或自扩展的关键字来实现这一点。比如：GCC为程序员提供了__restrict__或__restrict扩展关键字，有了这些关键字后，C程序员就可以显式地向编译器传达信息了。还以foo为例，我们看看加上__restrict__后编译器为函数foo生成的目标代码是什么样子的：

void foo(int *__restrict__ p, int *__restrict__ q, int * __restrict__r) {
    *p += *r;
    *q += *r ;
}

(gdb) disas foo
Dump of assembler code for function foo:
   0x080483c0 :    push   %ebp
   0x080483c1 :    mov    %esp,%ebp
   0x080483c3 :    mov    0×10(%ebp),%edx
   0x080483c6 :    mov    0×8(%ebp),%ecx
   0x080483c9 :    mov    0xc(%ebp),%eax
   0x080483cc :    mov    (%edx),%edx
   0x080483ce :    add    %edx,(%ecx)
   0x080483d0 :    add    %edx,(%eax)
   0x080483d2 :    pop    %ebp
   0x080483d3 :    ret   
End of assembler dump.

我们主要来看下面连续的三行汇编代码：
0x080483cc :    mov    (%edx),%edx ; *r -> %edx，将指针r指向的内存对象的值加载到寄存器edx中
0x080483ce :    add    %edx,(%ecx) ; *r + *p -> *p，将寄存器edx中的数值与指针p所指内存对象的值相加，结果存放在指针p所指的内存对象中
0x080483d0 :    add    %edx,(%eax) ; *r + *q -> *q，将寄存器edx中的数值与指针q所指内存对象的值相加，结果存放在指针q所指的内存对象中

可以看到这次编译器生成了优化后的代码，第二次加法操作直接用的是缓存在寄存器中的*r值。以上就是C99引入restrict关键字的一个基本考虑，通过restrict，C程序员可以告知编译器大胆地去执行优化，程序员来保证代码符合restrict语义的约束要求，这可以看作是一种程序员与编译器间的契约。

前面说过restrict是一种类型修饰符，但不同于其他两种修饰符const和volatile，restrict仅用于修饰指针类型与不完整类型(incomplete types)，C99规范中对restrict的诠释是这样的："Types other than pointer types derived from object or incomplete types shall not be restrict-qualified"。用restrict修饰指针是最常见的情况，被restrict修饰的指针到底有何与众不同呢？

用restrict修饰某指针变量意味着在该指针变量的生命周期内，该指针是其所指内存对象的唯一访问和修改入口，即所有对其所指的内存对象数据的访问和修改都是通过该指针完成的。或是说在特定上下文中该指针所指的内存对象不存在别名(Alias)。何为别名？引用同一内存对象的多个变量互为别名。比如：
int a = 5;
int *p = &a;
int *q = p;

这样p, q, a互为别名，它们都引用到地址&a。另外如果两个指针所指向的内存对象有相互重叠，那相互也算做是一种别名。

restrict的语义约束可以分成两个方面，一个是对内部的，一个是对外部的。我们还以上面的foo函数为例，这里稍作改动，去掉p，q两个参数的restrict修饰：

void foo(int *p, int *q, int *restrict r) {
    *p += *r;
    *q += *r ;
}

从foo内部来看，r是一个被restrict修饰的指针，其生命周期从foo执行开始一直到foo执行结束。按照上面对restrict的诠释，在foo函数内部不应该存在指针r所指内存对象的别名，即不应该存在下面情况：

void foo(int *p, int *q, int *restrict r) {
    int *z = r;
    …later, use r and z…
}

这的约束是foo的实现者保证的。

对于外部而言，即foo的使用者依然要保证传入实参后p或q不是r所指内存对象的别名，下面这样的代码将违反约束：
int a = 5;
int b = 6;
foo(&a, &b, &b);

这里还有一个问题：虽然r用了restrict修饰符，但编译器在看到void foo(int *p, int *q, int *restrict r)这个函数原型后就一定会生成优化的代码吗？显然通过这个原型信息，编译器依旧无法保证p或q不是r所指内存地址的别名，所以对上面这段代码编译器无法给出优化，即使r是被restrict修饰的，至少在我的Ubuntu gcc 4.4.3上是不会生成优化目标代码的。也就是说这个例子中foo的设计者与编译器之间的契约不够充分，无法让Compiler完全信服地去执行优化。这就需要进一步的补充契约，也就是让Compiler意识到p, q, r在foo中都是各自所指内存地址的唯一入口，为了达到这一点，我们只能为p, q也加上restrict修饰，这样契约变成foo内部的p, q, r是给自所指内存的唯一入口，p, q, r也就不可能是对方的别名了。

但即使所有指针参数都加上restrict修饰，Compiler就一定会生成优化的代码吗，事实是也不一定。看下面例子：
void foo1(int *restrict p, int *restrict q, char *restrict r) {
    *p += (int)*r;
    *q += (int)*r;
}
void foo2(int *restrict p, int *restrict q, long long int *restrict r) {
    *p += (int)*r;
    *q += (int)*r;
}

可以看到我们分别将foo函数的最后一个参数r的类型换为了char*和long long int*并,形成两个函数foo1和foo2，我们尝试用GCC生成对应的目标代码，通过反编译，我们可以得到如下结果：

(gdb) disas foo1
Dump of assembler code for function foo1:
   0×08048430 :    push   %ebp
   0×08048431 :    mov    %esp,%ebp
   0×08048433 :    mov    0×10(%ebp),%edx
   0×08048436 :    mov    0×8(%ebp),%ecx
   0×08048439 :    mov    0xc(%ebp),%eax
   0x0804843c :    push   %ebx
   0x0804843d :    movsbl (%edx),%ebx
   0×08048440 :    add    %ebx,(%ecx)
   0×08048442 :    movsbl (%edx),%edx
   0×08048445 :    add    %edx,(%eax)
   0×08048447 :    pop    %ebx
   0×08048448 :    pop    %ebp
   0×08048449 :    ret   
End of assembler dump.

(gdb) disas foo2
Dump of assembler code for function foo2:
   0×08048450 :    push   %ebp
   0×08048451 :    mov    %esp,%ebp
   0×08048453 :    mov    0×10(%ebp),%edx
   0×08048456 :    mov    0×8(%ebp),%ecx
   0×08048459 :    mov    0xc(%ebp),%eax
   0x0804845c :    mov    (%edx),%edx
   0x0804845e :    add    %edx,(%ecx)
   0×08048460 :    add    %edx,(%eax)
   0×08048462 :    pop    %ebp
   0×08048463 :    ret   
End of assembler dump.

我们可以看到GCC只为foo2生成了优化后的代码，而foo1并未被优化。这个结果让人有些摸不着头脑。难道编译器认为char*指针有成为int*指针所指对象的alias的潜在可能，而int*指针无法成为long long int*指针所指对象的alias？在C99规范中我也没能找到解释这一现象的答案。看来即使增加了restrict，编译器也是有选择的信任，至少Gcc是这样的。

restrict的作用范围与其修饰的指针的生命周期一致，你可以声明文件作用域(file scope)的restrict指针变量，也可以在某个代码block中使用restrict指针。如果某个结构体成员是restrict pointer类型，那该指针的生命周期就等同于该结构体实例的生命周期。

如果你恶意破坏你和Compiler之间的契约，别指望Compiler会有Warning提示，Compiler在这方面是完全信赖程序员的，不确定行为不可避免。比如：
void foo(int *restrict p, int *restrict q, int *restrict r) {
    *p += *r;
    *q += *r;
}

int main() {
    int a = 1;
    int b = 2;
    int c = 3;
    foo(&a, &b, &a);
    printf("a = %d, b = %d, c = %d\n", a, b, c);
}
执行优化后的程序，我们得到的输出为：
$ a.out
a = 2, b = 4, c = 3
这显然与预期的a = 2, b = 3, c = 3不符，错误原因就在于你单方面违反了restrict契约。

C99规范中对restrict关键字的讲解还算不少，甚至还给出了formal definition(C99 6.7.3.1)，不过这个定义简直就像一段天书，实在是晦涩难懂(《The New C Standard》一书对此有逐句的解释，不过依旧很难理解)。另外restrict的存在对程序本身的语义没有任何影响，对于不支持restrict的编译器也大可忽略restrict修饰符。

至于在平时开发中如何使用restrict，我个人觉得最好是在有一定理解的前提下使用。这对C程序员能力还是有一定要求的。首先要明确你编写的函数内部是否有可以优化的地方，如果根本没有可优化的潜力，那使用restrict就画蛇添足了；当然还有一种情况下你用restrict并不是期望编译器给予优化，而是你的实现算法是基于参数指针所指内存对象无alias的前提的，你在函数原型中用restrict修饰参数主要是想将你的意图告知该函数的使用者；第二要知道restrict对函数内部实现的约束，不要在内部实现时违反约束，导致未定义行为；第三如果你是一个使用者，面对采用了restrict修饰的函数接口，如void *memcpy(void * restrict s1, const void * restrict s2, size_t n)，你要注意不能违反restrict约束，否则也会导致未定义行为。如果你是一个公共库的开发者，你更应该尽量采用restrict，这对你的库代码的性能会是大有裨益的。