花了点时间把svnbook看了遍，对于svn有了个比较好的认识。svn info时，修订版和最后修改的修订版总是让我感觉很困惑。要搞明白这个需要对下面几个关键字有所了解。

HEAD：版本库中的最新版本。

COMMITED：文件最后提交生成的版本号。

PREV：文件倒数第二次提交生成的版本号。

BASE：目录签出或者签入生成的版本号。

HEAD、COMMITED和PREV比较好理解，BASE比较难于理解。假设一个目录下有两个文件configure.ac和Makefile.am，第一次将它们check out出来时，会生成一个新的revision，这个便是BASE了。此时使用svn info configure.ac/Makefile.am可以发现它们的修订版是一样的，但是最后修改的修订版不同。这里的修订版对应其实就是BASE，而最后修改的修订版则是COMMITED。插一句，很多人很容易误解为啥修订版号和最后修改的修订版号不一致。

若将configure.ac修改并check in，这个时候会生成一个新的revision，configure.ac的BASE和COMMITED的值相当。而svn info Makefile.am，发现它的BASE和COMMITED没有改变。svn up一下，发现Makefile.am的BASE会变成最新的，和configure.ac相同。

签出代码库。

显示修订版（BASE）和最后修改的修订版（COMMITED）。

修改Makefile.am并签入看看。

svn update一下看看。

svn一个版本库的revision是全局的，不管是在trunk还是branch，也不管使用merge合并代码还是消除修改，签入和签出都会生成一个新的revision。当项目中一个文件签入时会导致别的文件的BASE暂时低于HEAD，但是一旦update，二者将保持一致。

unset LANGUAGE
export LANG="en"
cd /home/kingsoft
mkdir distcc
cd distcc

rpm包用：rpm -ivh ...
bz2包用：tar -xvf ...
进入distcc解压后的目录
./configure && make && make install
mkdir /usr/lib/distcc
mkdir /usr/lib/distcc/bin
cd /usr/lib/distcc/bin
ln -s /usr/local/bin/distcc gcc
ln -s /usr/local/bin/distcc cc
ln -s /usr/local/bin/distcc g++
ln -s /usr/local/bin/distcc c++

进入ccache解压目录
./configure && make && make install

mkdir /Data
mkdir /Data/Cache
mkdir /Data/Cache/CCache
cd /Data/Cache
touch /var/log/distccd.log

vim ~/.bash_profile
把 /usr/lib/distcc/bin 加到PATH
并添加下面内容
## ----- Distcc -----
#
DISTCC_HOSTS="localhost 192.168.1.1"
DISTCC_VERBOSE=1
DISTCC_LOG="/var/log/distcc.log"
export DISTCC_HOSTS PATH DISTCC_VERBOSE DISTCC_LOG
#
## ----- End -----

## ----- Ccache -----
#
# export CCACHE_DISABLE=1
CCACHE_DIR=/Data/Cache/CCache
CCACHE_LOGFILE=/Data/Cache/CCache.log
CCACHE_PREFIX="distcc"
CC="ccache gcc"
CXX="ccache g++"
export CCACHE_DIR CCACHE_LOGFILE CCACHE_PREFIX CC CXX
#
## ----- End -----

vim /etc/rc.local
distccd --daemon --allow 10.20.0.0/16

==========================================
启动监控：distccd --daemon --allow 10.20.0.0/16
查看监控：distccmon-text 1

Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。

举个例子，比如之前的blog中的实验，一开始client端调用socket的write操作将一个int型数据(称为A块)写入到网络中，由于此时连接是空闲的（也就是说还没有未被确认的小段），因此这个int型数据会被马上发送到server端，接着，client端又调用write操作写入‘\r\n’（简称B块），这个时候，A块的ACK没有返回，所以可以认为已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到（大概40ms之后），B块才被发送。整个过程如图所示：

这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是因为TCP/IP中不仅仅有nagle算法，还有一个ACK延迟机制 。当Server端收到数据之后，它并不会马上向client端发送ACK，而是会将ACK的发送延迟一段时间（假设为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么'\r\n'(B块)总是在A块之后40ms才发出。

如果你觉着nagle算法太捣乱了，那么可以通过设置TCP_NODELAY将其禁用 。当然，更合理的方案还是应该使用一次大数据的写操作，而不是多次小数据的写操作。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/historyasamirror/archive/2011/05/15/6423235.aspx

ldd查看应用程序链接了哪些动态库。

nm列出目标文件中包含的符号信息。

size列出各个段的大小及总的大小。

strings列出文件中的字符串。

readelf读取elf文件的完整结构。

objdump导出目标文件的相关信息（elf文件相关工具的源头）。

gdb对文件的执行过程进行调试分析，设置断点(b)、单步执行(n)、函数调用追踪(bt)、反汇编(disassemble)。

strace跟踪程序中的系统调用及信号处理信息。

LD_DEBUG通过设置这个环境变量，可以方便的看到 loader 的加载过程（包括库的加载，符号解析等过程），使用【LD_DEBUG=help 可执行文件路径】可查看使用帮助。

LD_PRELOAD环境变量指定的共享库会被预先加载，如果出现重名的函数，预先加载的函数将会被调用，如在预先加载的库中包含自定义的puts函数，则在执行程序时将使用自定义版本的puts函数，而不是libc库中的puts函数。

proc文件系统中包含进程的地址空间映射关系，具体查看/proc/进程id/maps文件的内容。

valgrind工具对可执行程序文件进行内存检查（还有cache模拟、调用过程跟踪等功能），以避免内存泄露等问题。

addrline将可执行文件中的地址转换为其在源文件中对应的位置（文件名：行号）。

处理器总处于以下状态中的一种：
１、内核态，运行于进程上下文，内核代表进程运行于内核空间；
２、内核态，运行于中断上下文，内核代表硬件运行于内核空间；
３、用户态，运行于用户空间。

用户空间的应用程序，通过系统调用，进入内核空间。这个时候用户空间的进程要传递很多变量、参数的值给内核，内核态运行的时候也要保存用户进程的一些寄存器值、变量等。所谓的“进程上下文”，可以看作是用户进程传递给内核的这些参数以及内核要保存的那一整套的变量和寄存器值和当时的环境等。

硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理。所谓的“中断上下文”，其实也可以看作就是硬件传递过来的这些参数和内核需要保存的一些其他环境（主要是当前被打断执行的进程环境）。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/eroswang/archive/2007/11/28/1905830.aspx

在实模式下没有引入段式内存管理模式前,程序都是使用绝对地址来进行内存操作的,这样造成了程序的可移植性差等问题。于 是在8086时代开始引入段式内存管理,段式管理引入了地址映射的概念,不但解决了可移植性问题，也解决了16位ALU和段寄存器的可寻址限制,即支持更 大的内存寻址.每个段的大小是64KB.

在实模式下,由于系统程序和用户程序在访问内存等资源时权限没有区分,所以很可能造成操作系统出现异常.于是Intel在80286时代开发出来了保护模式.

而Intel为了兼容80386前的处理器就规定：在IA(Intel Arch)32保护模式下，不能禁止分段，但是分页是Optional的。/*When operating in protected mode, some form of segmentation must be used. There is no mode bit to disable segmentation. The use of paging, however, is optional.*/.

既然linux在内存管理上不能禁止分段,那么linux又认为分段会造成大量的内存碎片,所以就通过将逻辑地址中的段基址置为0,加上偏移量形成线性地址,来简化段式管理内存而使用分页管理内存的。

在IA32下,每页是4K.

二、linux的三种类型内存地址及关系是什么样的？

分段                     分页

逻辑地址————> 线性地址 —————->物理地址

在 x86 架构中，内存被划分成 3 种类型的地址：

逻辑地址 (logical address) 由16位段选择符:32位偏移量来表示，它有可能直接对应于一个物理位置(Intel实模式下)。

线性地址 (linear address)或虚拟地址 是由段描述符中的32位段基址和逻辑地址中的32位偏移量相加构成的。例如:0x08048394,由于linux把所有的段基址都置为0x00000000.所以线性地址=0x00000000+偏移量=逻辑地址,在不分页的情况下：线性地址就直接是物理地址;

物理地址 (physical address) 是使用物理地址总线中的位表示的地址。内存管理单元可以将逻辑地址转换成物理地址。

三、为什么在32位的操作系统下每个进程会有4G的内存使用限制?

由于32位操作系统下,由于虚拟地址空间是2的32次方=4 294 967 296,通常的数据对象都以字节为单位,所以一个进程的可寻址范围就是4G内存

四、为什么linux服务器是32位的还可以认出来多于4G的内存?

本来在IA32下,机器只能认出4G的内存,但Intel为了让32位的OS能支持更多的内存。采取了PAE(Physical Address Extension, 物理地址扩展)技术.PAE的支持,不仅需要处理器的支持,OS的内核也需要支持才可行(我们通常采用的RHEL3/4/5 kernel都支持PAE),也就是处理器内部增加了PAE寄存器,用于记录多出的4条地址总线，所以系统就是2^36=64G.

五、在32位的linux操作系统下,为什么linux系统认出来的内存大于4G,而我的程序每个进程却只能分配4G以下的内存?

虽然Intel为其处理器为支持PAE增加了4条地址线，但因为虚拟地址是32位的,所以单个进程还是只能分配4G以下的内存

Note: Linux can use up to 64 Gigabytes of physical memory on x86 systems. However, the address space of 32-bit x86 processors is only 4 Gigabytes large. Thus means that, if you have a large amount of physical memory, not all of it can be “permanently mapped” by the kernel. The physical memory that’s not permanently mapped is called “high memory”.

Redhat网站http://www.redhat.com/rhel/compare/

六、32位的RedHat linux在”smp” kernel和”hugemem” kernel中内存支持方面有什么建议?

Smp kernel和hugemem kernel都支持PAE支持,也就意味着最大能支持64G的内存。而RedHat建议当你的物理内存在16GB之内,用SMP” kernel,在16GB-64GB之间使用”Hugemem” kernel.这是因为虚拟地址空间里有1G用于内核空间，而3G用于用户空间。而关健的一些数据结构是存放在1G内核空间的，在管理32G内存当中，需 要用到0.5G来用于管理这些物理内存(容易触发OOM killer).虽然32位OS下,内核和用户空间的比例都是1：3，但Hugemem打了一个补丁,使比例成为4G:4G,即使内核空间和用户空间相互 独立，所以也会有性能上的损失,因为应用程序的运行,通常会有内核和用户空间的切换。所以如果你的内存大于16G,建议你使用64位的OS。

/* The “SMP” kernel supports a maximum of 16GB of main memory. Systems with more than 16GB of main memory use the “Hugemem” kernel. In certain workload scenarios it may be advantageous to use the “Hugemem” kernel on systems with more than 12GB of main memory. */

七、我们通常malloc了4K内存,到底是怎么对应到物理内存的？

在linux下,处理器在得到内存的线性地址进行内存寻址时，不是直接在内存的物理地址里查找的，而是通过线性地址转换到主内存的物理地 址，TLB(Translation lookaside buffer,可以简单的理解为:一种存储线性地址和物理地址的硬件高速缓冲器)就是负责将虚拟内存地址翻译成实际的物理内存地址，而CPU寻址时会优先 在TLB中进行寻址。如果TLB里没有,则从页表里进行线性地址到物理地址的转换.hugepage能增加TLB的命中率，所以会在某些方面能大大提高系 统性能)。

1、逻辑地址转线性地址

a、首先根据指令的性质来确定该使用哪一个段寄存器。
b、根据段寄存器的内容，到GDT中找到相应的“段描述结构”

c、根据linux把所有的段基址都置为0×00000000.所以0×00000000+偏移量就是线性地址了.在不分页的情况下：线性地址就直接是物理地址;
同时，在上面过程中，由于有对访问权限的检查，就实现了保护。

2、线性地址转物理地址

在保护模式下，控制寄存器CR0的最高位PG位(PE位控制是否为保护模式)控制着分页管理机制是否生效，如果PG=1，分页机制生效，需通过页表查找才能把线性地址转换物理地址。如果PG=0，则分页机制无效，线性地址就直接做为物理地址。

页式内存管理中，32位的线性地址划分为三个部分：10位的页目录表下标、10位的页面表下标、12位的页内偏移量。CPU增加了一个CR3寄存器存放指向当前页目录表的指针。寻址方式就改为：
a、从CR3取得页目录表的基地址；
b、根据10位页目录表下标和从CR3取得的基地址，得到相应页表的基地址；
c、根据10位页面表下标和b中得到的页表基地址，从页面表中取得相应的页面描述项；
d、将页面描述项中的页面基地址和线性地址中的12位页内地址偏移相加，得到物理地址。
同时，在地址转换的过程中也有越界和权限的检查，就不赘述了。

注:传统的32位操作系统采用的是两级分页模型

64位和PAE支持都采用了三级分页模型

1进程启动的时候，其（虚拟）内存空间的初始布局如图1所示。其中，mmap内存映射文件是在堆和栈的中间（例如libc-2.2.93.so，其它数据文件等），为了简单起见，省略了内存映射文件。_edata指针（glibc里面定义）指向数据段的最高地址。
2 进程调用A=malloc(30K)以后，内存空间如图2：malloc函数会调用brk系统调用，将_edata指针往高地址推30K，就完成虚拟内存 分配。你可能会问：只要把_edata+30K就完成内存分配了？事实是这样的，_edata+30K只是完成虚拟地址的分配，A这块内存现在还是没有物 理页与之对应的，等到进程第一次读写A这块内存的时候，发生缺页中断，这个时候，内核才分配A这块内存对应的物理页。也就是说，如果用malloc分配了 A这块内容，然后从来不访问它，那么，A对应的物理页是不会被分配的。
3进程调用B=malloc(40K)以后，内存空间如图3.

4进程调用C=malloc(200K)以后，内存空间如图4：默认情况下，malloc函数分配内存，如果请求内存大于128K（可由 M_MMAP_THRESHOLD选项调节），那就不是去推_edata指针了，而是利用mmap系统调用，从堆和栈的中间分配一块虚拟内存。这样子做主 要是因为brk分配的内存需要等到高地址内存释放以后才能释放（例如，在B释放之前，A是不可能释放的），而mmap分配的内存可以单独释放。当然，还有 其它的好处，也有坏处，再具体下去，有兴趣的同学可以去看glibc里面malloc的代码了。
5进程调用D=malloc(100K)以后，内存空间如图5.
6进程调用free(C)以后，C对应的虚拟内存和物理内存一起释放

4进程调用C=malloc(200K)以后，内存空间如图4：默认情况下，malloc函数分配内存，如果请求内存大于128K（可由 M_MMAP_THRESHOLD选项调节），那就不是去推_edata指针了，而是利用mmap系统调用，从堆和栈的中间分配一块虚拟内存。这样子做主 要是因为brk分配的内存需要等到高地址内存释放以后才能释放（例如，在B释放之前，A是不可能释放的），而mmap分配的内存可以单独释放。当然，还有 其它的好处，也有坏处，再具体下去，有兴趣的同学可以去看glibc里面malloc的代码了。
5进程调用D=malloc(100K)以后，内存空间如图5.
6进程调用free(C)以后，C对应的虚拟内存和物理内存一起释放

7进程调用free(B)以后，如图7所示。B对应的虚拟内存和物理内存都没有释放，因为只有一个_edata指针，如果往回推，那么D这块内存怎 么办呢？当然，B这块内存，是可以重用的，如果这个时候再来一个40K的请求，那么malloc很可能就把B这块内存返回回去了。
8进程调用free(D)以后，如图8所示。B和D连接起来，变成一块140K的空闲内存。
9默认情况下：当最高地址空间的空闲内存超过128K（可由M_TRIM_THRESHOLD选项调节）时，执行内存紧缩操作（trim）。在上一个步骤free的时候，发现最高地址空闲内存超过128K，于是内存紧缩，变成图9所示。

真相大白
说 完内存分配的原理，那么被测模块在内核态cpu消耗高的原因就很清楚了：每次请求来都malloc一块2M的内存，默认情况下，malloc调用mmap 分配内存，请求结束的时候，调用munmap释放内存。假设每个请求需要6个物理页，那么每个请求就会产生6个缺页中断，在2000的压力下，每秒就产生 了10000多次缺页中断，这些缺页中断不需要读取磁盘解决，所以叫做minflt；缺页中断在内核态执行，因此进程的内核态cpu消耗很大。缺页中断分 散在整个请求的处理过程中，所以表现为分配语句耗时（10us）相对于整条请求的处理时间（1000us）比重很小。

解决办法
将动态内存改为静态分配，或者启动的时候，用malloc为每个线程分配，然后保存在threaddata里面。但是，由于这个模块的特殊性，静态分配，或者启动时候分配都不可行。另外，Linux下默认栈的大小限制是10M，如果在栈上分配几M的内存，有风险。
禁止malloc调用mmap分配内存，禁止内存紧缩。
在进程启动时候，加入以下两行代码：
mallopt(M_MMAP_MAX, 0); // 禁止malloc调用mmap分配内存
mallopt(M_TRIM_THRESHOLD, -1); // 禁止内存紧缩
效果：加入这两行代码以后，用ps命令观察，压力稳定以后，majlt和minflt都为0。进程的系统态cpu从20降到10。

小结
可以用命令ps -o majflt minflt -C program来查看进程的majflt, minflt的值，这两个值都是累加值，从进程启动开始累加。在对高性能要求的程序做压力测试的时候，我们可以多关注一下这两个值。
如果一个进程使用了mmap将很大的数据文件映射到进程的虚拟地址空间，我们需要重点关注majflt的值，因为相比minflt，majflt对于性能的损害是致命的，随机读一次磁盘的耗时数量级在几个毫秒，而minflt只有在大量的时候才会对性能产生影响。

在日常系统管理工作中，需要编写脚本来完成特定的功能，编写shell脚本是一个基本功了！
在编写的过程中，掌握一些常用的技巧和语法就可以完成大部分功能了，也就是2/8原则.

1. 单引号和双引号的区别

单引号与双引号的最大不同在于双引号仍然可以引用变量的内容，但单引号内仅是 普通字符 ，不会作变量的引用，直接输出字符窜。请看如下例子：

  [root@linux ~]# name=HaHa

[root@linux ~]# echo $name

HaHa

[root@linux ~]# myname="$name is wow"

[root@linux ~]# echo $myname

HaHa is wow

[root@linux ~]# myname='$name is wow'

[root@linux ~]# echo $myname

$name is wow

从上面例子可以看出,使用了单引号的时候，那么$name只是普通字符,直接输出而已！

2. 逐行读取文件

• 使用for循环来读取文件

    for line in `cat file.txt`
  
      do
  
      echo $line
  
      done

注意:由于使用for来读入文件里的行时，会自动把空格和换行符作为一样分隔符，如果行里有空格的时候，输出的结果会很乱，所以只适用于行连续不能有空格或者换行符的文件

• 使用while循环读取文件

    cat file.txt |while read line
  
      do
  
      echo $line
  
      done
  
      
  
      或者：
  
      
  
      while read line
  
      do
  
      echo $line
  
      done < file.txt

注意:由于使用while来读入文件里的行时，会整行读入，不会关注行的内容(空格..)，所以比for读文件有更好的适用性，推荐使用while循环读取文件

3. bash shell 脚本中常用隐含变量

注意: $? 用于检查上一个命令执行是否正确(在Linux中，命令退出状态为0表示该命令正确执行，任何非0值表示命令出错)
$$ 变量最常见的用途是用做暂存文件的名字以保证暂存文件不会重复。
$* 和 $@ 如果输出是一样的，但是在使用for循环，在使用 双引号(”")引用时 “$*” 会输出成一个元素 而 “$@” 会按照每个参数是一个元素方式输出

请看测试例子

  #cat test.sh

#!/bin/sh

echo '"$@" output.....'

for i in "$@"

do

echo $i

done

echo '"$*" output ....'

for i in "$*"

do

echo $i

done

输出结果

  #sh test.sh a b c d

"$@" output.....

a

b

c

d

"$*" output ....

a b c d

从输出结果可以看出 “$*” 输出是一行 而 “$@” 输出则是四行

4. 变量内容的删除与替换

我们在一些情况下，需要对变量中的字符窜进行查找删除或者替换，就需要使用下表列出的方法

举例如下(删除字符窜中的某个字符):

  [root@linux ~]# export test_str="/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin"

[root@linux ~]# echo ${test_str#/*kerberos/bin:}

/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

5. 变量条件测试赋值

在某些时刻我们需要‘判断’某个变量是否存在，若变量存在则将此变量值赋值给新的变量，若变量不存在则将其他值赋值给新的变量.

举例如下:

  [root@linux ~]# test_name=""

[root@linux ~]# test_name=${test_name-root}

[root@linux ~]# echo $test_name

<== 因为 test_name 被设定为空字符窜！所以当然还是保留为空字符窜！

[root@linux ~]# test_name=${test_name:-root}

[root@linux ~]# echo $test_name

root  <== 加上‘:’后若变量内容为空或者是未设定，都能够以后面的内容替换！

基本上这种变量的测试也能够透过 shell script 内的 if…then… 来处理,不过通过上述提及的简单的方法来测试变量，是程序看起来更精简一些！

6. shell 中分隔符 : 变量IFS 使用

shell脚本中，如果使用for循环一个字符窜的话，默认使用空格来分割字符窜. 还有前面所提到的 使用for循环逐行读取文件内容时候,文件行中如果有空格的话输出的结果也会变乱. 这个时候 使用 IFS 变量来设置特定的字符窜分割符来，达到输出正确的目的. 默认情况下 IFS 是使用 <space><tab><newline>， 空格 "t "n 来作为默认的分割符的.

我们将前面使用for逐行读取文件的例子 改进下就可以输出正确了,请看下面

  #!/bin/bash

IFS_old=$IFS      #将原IFS值保存，以便用完后恢复

IFS=$’"n’         #更改IFS值为$’"n’

for line in `cat file.txt`

do

echo $line

done

file.txt 文件内容如下

  [root@linux]$ cat file.txt

sdfsdfsdfsdf

ssssss ssssss ssssss sssss

sdfsdfsdfsdfsdf

执行测试程序 输出结果如下(正确输出)

  [root@linux]$ sh test.sh

sdfsdfsdfsdf

ssssss ssssss ssssss sssss

sdfsdfsdfsdfsdf

如果未设置IFS变量,使用默认的IFS变量值 ,输出结果如下

  [root@linux]$ sh test.sh

sdfsdfsdfsdf

ssssss

ssssss

ssssss

sssss

sdfsdfsdfsdfsdf

从以上测试程序输出结果,可以根据自己的需求来设定 IFS变量,在举一个例子如下:

  while IFS=: read userName passWord userID groupID geCos homeDir userShell

do

echo "$userName -> $homeDir"

done < /etc/passwd

7. shell 数组的使用

数组赋值方式:

  (1) array=(var1 var2 var3 ... varN)

(2) array=([0]=var1 [1]=var2 [2]=var3 ... [n]=varN)

(3) array[0]=var1

arrya[1]=var2

...

array[n]=varN

计算数组元素个数或者长度:

  (1) ${#array[@]}

(2) ${#array[*]}

了解了数组基础语法，举例说明，请看:

  #!/bin/bash

NAMESERVERS=("ns1.www.net." "ns2.www.net." "ns3.www.net.")

# 得到数组长度

tLen=${#NAMESERVERS[@]}



# 循环数组

for (( i=0; i<${tLen}; i++ ));

do

echo ${NAMESERVERS[$i]}

done

在看一个复杂一点的例子,将文件内容读取到数组中:

  #!/bin/bash



# 设置IFS将分割符 设置为 换行符("n)

OLDIFS=$IFS

IFS=$'"n' 



# 读取文件内容到数组

fileArray=($(cat file.txt))



# restore it

IFS=$OLDIFS

tLen=${#fileArray[@]}



# 循环显示文件内容

for (( i=0; i<${tLen}; i++ ));

do

echo "${fileArray[$i]}"

done

8. 逻辑判断 条件测试

• 文件属性的判断

举例如下,测试文件是否存在:

  #!/bin/bash

echo "checks the existence of the messages file."

echo -n "Checking..."

if [ -f /var/log/messages ];then

echo "/var/log/messages exists."

fi

echo

echo "...done."

• 字符串比较

举例如下,比较字符串来测试用户ID :

  if [ "$(whoami)" != 'root' ]; then

echo "You have no permission to run $0 as non-root user."

exit 1;

fi

• 数值比较(整数)

举例如下:

  num=`wc -l work.txt`

if [ $num -gt 150 ];then

echo "you've worked hard enough for today."

echo

fi

如果要查看详细的测试操作,可以查看man手册 man test

Ctrl-E 相当于End键，即将光标移动到本行末尾

Ctrl-B 相当于左箭头键，用于将光标向左移动一格

Ctrl-F 相当于右箭头键，用于将光标向右移动一格

Ctrl-D 相当于Del键，即删除光标所在处的字符

Ctrl-K 用于删除从光标处开始到结尾处的所有字符

Ctrl-L 清屏，相当于clear命令

Ctrl-R 进入历史命令查找状态，然后你输入几个关键字符，就可以找到你使用过的命令

Ctrl-U 用于删除从光标开始到行首的所有字符。一般在密码或命令输入错误时常用

Ctrl-H 删除光标左侧的一个字符

Ctrl-W 用于删除当前光标左侧的一个单词

Ctrl-P 相当于上箭头键，即显示上一个命令

Ctrl-N 相当于下箭头键，即显示下一个命令

Ctrl-T 用于颠倒光标所在处字符和前一个字符的位置。（目前不知道有什么作用，哪位朋友知道？）

Ctrl-J 相当于回车键

                    
        最底层使用伙伴算法管理内存页面。系统将所有空闲内存页面分10个组，每个组中的内存块大小依次是1，2，4……512个内存页面，每组中的内存块大小相 同，并且以链表结构保存。大小相同，并且内存地址连续的两个内存块称为伙伴。伙伴算法的中心思想就是将成为伙伴的空闲内存合并成一个更大的内存块。
        os中使用get_free_page获取空闲页面，如果找不到合适大小的空闲页面，则从更大的组中找到空闲内存块，分配出去，并将剩余内存分割，插入到 合适的组中。当归还内存时，启动伙伴算法合并空闲内存。如果不停的申请内存，并且部分归还，但归还的内存不能成为伙伴，长期运行后，所有内存将被分割成不 相邻的小块，当再次申请大块内存时，则可能由于找不到足够大的连续内存块而失败，这种零散的不相邻的小块内存称之为内存碎片。当然这只是理论上的说明，伙 伴算法本身就是为了解决内存碎片问题。

二  malloc子系统内存管理（dlmalloc)
        应用层面的开发并不是直接调用sbrk/mmap之类的函数，而是调用malloc/free等malloc子系统提供的函数，linux上安装的大多为 DougLea的dlmalloc或者其变形ptmalloc。下面以dlmalloc为例说明malloc工作的原理。
1 dlmalloc下名词解释：
   boundary tag: 边界标记，每个空闲内存块均有头部表识和尾部标识，尾部表识的作为是合并空闲内存块时更快。这部分空间属于无法被应用层面使用浪费的内存空间。
   smallbins: 小内存箱。dlmalloc将8,16,24……512大小的内存分箱，相临箱子中的内存相差8字节。每个箱子中的内存大小均相同，并且以双向链表连接。
   treebins: 树结构箱。大于512字节的内存不再是每8字节1箱，而是一个范围段一箱。比如512~640, 640~896…..每个箱子的范围段依次是128，256，512……。每箱中的结构不再是双向链表，而是树形结构。
   dv chunk:  当申请内存而在对应大小的箱中找不到大小合适的内存，则从更大的箱中找一块内存，划分出需要的内存，剩余的内存称之为dv chunk.
   top chunk: 当dlmalloc中管理的内存都找不到合适的内存时，则调用sbrk从系统申请内存，可以增长内存方向的chunk称为top chunk.
2 内存分配算法
        从合适的箱子中寻找内存块–>从相临的箱子中寻找内存块–>从dv chunk分配内存–>从其他可行的箱子中分配内存–>从top chunk中分配内存–>调用sbrk/mmap申请内存
3 内存释放算法
       临近内存合并–>如属于top chunk，判断top chunk>128k，是则归还系统
                              –>不属于chunk，则归相应的箱子

摘要：介绍了一个简单的字符设备驱动程序，深入剖析了write函数的工作原理

     在Linux下我们在使用设备的时候，都会用到write这个函数，通过这个函数我们可以象使

用文件那样向设备传送数据。可是为什么用户使用write函数就可以把数据写到设备里面

去，这个过程到底是怎么实现的呢？ 



这个奥秘就在于设备驱动程序的write实现中，这里我结合一些源代码来解释如何使得一

个简简单单的write函数能够完成向设备里面写数据的复杂过程。



这里的源代码主要来自两个地方。第一是oreilly出版的《Linux device driver》中的

实例，第二是Linux Kernel 2.2.14核心源代码。我只列出了其中相关部分的内容，如果

读者有兴趣，也可以查阅其它源代码。不过我不是在讲解如何编写设备驱动程序，所以不

会对每一个细节都进行说明，再说有些地方我觉得自己还没有吃透。



由于《Linux device driver》一书中的例子对于我们还是复杂了一些，我将其中的一个

例程简化了一下。这个驱动程序支持这样一个设备：核心空间中的一个长度为10的数组

kbuf[10]。我们可以通过用户程序open它，read它，write它，close它。这个设备的名

字我称为short_t。 



现在言归正传。 

对于一个设备，它可以在/dev下面存在一个对应的逻辑设备节点，这个节点以文件的形式

存在，但它不是普通意义上的文件，它是设备文件，更确切的说，它是设备节点。这个节

点是通过mknod命令建立的，其中指定了主设备号和次设备号。主设备号表明了某一类设

备，一般对应着确定的驱动程序；次设备号一般是区分是标明不同属性，例如不同的使用

方法，不同的位置，不同的操作。这个设备号是从/proc/devices文件中获得的，所以一

般是先有驱动程序在内核中，才有设备节点在目录中。这个设备号（特指主设备号）的主

要作用，就是声明设备所使用的驱动程序。驱动程序和设备号是一一对应的，当你打开一

个设备文件时，操作系统就已经知道这个设备所对应的驱动程序是哪一个了。这个"知道"

的过程后面就讲。 



我们再说说驱动程序的基本结构吧。这里我只介绍动态模块型驱动程序（就是我们使用

insmod加载到核心中并使用rmmod卸载的那种），因为我只熟悉这种结构。 

模块化的驱动程序由两个函数是固定的：int init_module(void) ；void

cleanup_module(void)。前者在insmod的时候执行，后者在rmmod的时候执行。 

init_nodule在执行的时候，进行一些驱动程序初始化的工作，其中最主要的工作有三

件：注册设备；申请I/O端口地址范围；申请中断IRQ。这里和我们想知道的事情相关的只

有注册设备。



下面是一个典型的init_module函数： 



int init_module(void){ 

int result = check_region(short_base,1)；/* 察看端口地址*/ 

…… 

request_region(short_base,1,"short"); /* 申请端口地址*/ 

…… 

result = register_chrdev(short_major, "short", &short_fops); /* 注册设备

*/ 

…… 

result = request_irq(short_irq, short_interrupt, SA_INTERRUPT, "short",

NULL); /* 申请IRQ */ 

…… 

return 0; 

}/* init_module*/ 



上面这个函数我只保留了最重要的部分，其中最重要的函数是 

result = register_chrdev(short_major, "short", &short_fops); 

这是一个驱动程序的精髓所在！！当你执行indmod命令时，这个函数可以完成三件大事：

第一，申请主设备号(short_major)，或者指定，或者动态分配；第二，在内核中注册设

备的名字("short")；第三，指定fops方法(&short_fops)。其中所指定的fops方法就是

我们对设备进行操作的方法（例如read,write,seek,dir,open,release等），如何实现

这些方法，是编写设备驱动程序大部分工作量所在。 



现在我们就要接触关键部分了--如何实现fops方法。 

我们都知道，每一个文件都有一个file的结构，在这个结构中有一个file_operations的

结构体，这个结构体指明了能够对该文件进行的操作。



下面是一个典型的file_operations结构： 

struct file_operations { 

loff_t (*llseek) (struct file *, loff_t, int); 

ssize_t (*read) (struct file *, char *, size_t, loff_t *); 

ssize_t (*write) (struct file *, const char *, size_t, loff_t *); 

int (*readdir) (struct file *, void *, filldir_t); 

unsigned int (*poll) (struct file *, struct poll_table_struct *); 

int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned

long); 

int (*mmap) (struct file *, struct vm_area_struct *); 

int (*open) (struct inode *, struct file *); 

int (*flush) (struct file *); 

int (*release) (struct inode *, struct file *); 

int (*fsync) (struct file *, struct dentry *); 

int (*fasync) (int, struct file *, int); 

int (*check_media_change) (kdev_t dev); 

int (*revalidate) (kdev_t dev); 

int (*lock) (struct file *, int, struct file_lock *); 

}; 



我们可以看到它实际上就是许多文件操作的函数指针，其中就有write，其它的我们就不

去管它了。这个write指针在实际的驱动程序中会以程序员所实现的函数名字出现，它指

向程序员实现的设备write操作函数。下面就是一个实际的例子，这个write函数可以向核

心内存的一个数组里输入一个字符串。 



int short_write (struct inode *inode, struct file *filp, const char *buf,

int count){ 

int retval = count; 

extern unsigned char kbuf[10]; 



if(count>10) 

count=10; 

copy_from_user(kbuf, buf, count); 

return retval; 

}/* short_write */ 

设备short_t对应的fops方法是这样声明的： 

struct file_operations short_fops = { 

NULL, /* short_lseek */ 

short_read, 

short_write, 

NULL, /* short_readdir */ 

NULL, /* short_poll */ 

NULL, /* short_ioctl */ 

NULL, /* short_mmap */ 

short_open, 

short_release, 

NULL, /* short_fsync */ 

NULL, /* short_fasync */ 

/* nothing more, fill with NULLs */ 

}; 



其中NULL的项目就是不提供这个功能。所以我们可以看出short_t设备只提供了

read,write,open,release功能。其中write功能我们在上面已经实现了，具体的实现函

数起名为short_write。这些函数就是真正对设备进行操作的函数，这就是驱动程序的一

大好处：不管你实现的时候是多么的复杂，但对用户来看，就是那些常用的文件操作函数。



但是我们可以看到，驱动程序里的write函数有四个参数，函数格式如下： 

short_write (struct inode *inode, struct file *filp, const char *buf, int count) 

而用户程序中的write函数只有三个参数，函数格式如下： 

write(inf fd, char *buf, int count) 

那他们两个是怎么联系在一起的呢？这就要靠操作系统核心中的函数sys_write了，下面

是Linux Kernel 2.2.14中sys_write中的源代码： 

asmlinkage ssize_t sys_write(unsigned int fd, const char * buf, size_t count) 

{ 

ssize_t ret; 

struct file * file; 

struct inode * inode; 

ssize_t (*write)(struct file *, const char *, size_t, loff_t *); /* 指向

驱动程序中的wirte函数的指针*/ 



lock_kernel(); 

ret = -EBADF; 

file = fget(fd); /* 通过文件描述符得到文件指针 */ 

if (!file) 

goto bad_file; 

if (!(file->f_mode & FMODE_WRITE)) 

goto out; 

inode = file->f_dentry->d_inode; /* 得到inode信息 */ 

ret = locks_verify_area(FLOCK_VERIFY_WRITE, inode, file, file->f_pos,

count); 

if (ret) 

goto out; 

ret = -EINVAL; 

if (!file->f_op || !(write = file->f_op->write)) /* 将函数开始时声明的

write函数指针指向fops方法中对应的write函数 */ 

goto out; 

down(&inode->i_sem); 

ret = write(file, buf, count, &file->f_pos); /* 使用驱动程序中的write函数

将数据输入设备，注意看，这里就是四个参数了 */ 

up(&inode->i_sem); 

out: 

fput(file); 

bad_file: 

unlock_kernel(); 

return ret; 

} 



我写了一个简单的程序来测试这个驱动程序，该程序源代码节选如下（该省的我都省了）： 



main(){ 

int fd,count=0; 

unsigned char buf[10]; 

fd=open("/dev/short_t",O_RDWR); 

printf("input string:"); 

scanf("%s",buf); 

count=strlen(buf); 

if(count>10) 

count=10; 

count=write(fd,buf,count); 

close(fd); 

return 1; 

} 



现在我们就演示一下用户使用write函数将数据写到设备里面这个过程到底是怎么实现的： 

1，insmod驱动程序。驱动程序申请设备名和主设备号，这些可以在/proc/devieces中获得。 

2，从/proc/devices中获得主设备号，并使用mknod命令建立设备节点文件。这是通过主

设备号将设备节点文件和设备驱动程序联系在一起。设备节点文件中的file属性中指明了

驱动程序中fops方法实现的函数指针。 

3，用户程序使用open打开设备节点文件，这时操作系统内核知道该驱动程序工作了，就

调用fops方法中的open函数进行相应的工作。open方法一般返回的是文件标示符，实际

上并不是直接对它进行操作的，而是有操作系统的系统调用在背后工作。 

4，当用户使用write函数操作设备文件时，操作系统调用sys_write函数，该函数首先通

过文件标示符得到设备节点文件对应的inode指针和flip指针。inode指针中有设备号信

息，能够告诉操作系统应该使用哪一个设备驱动程序，flip指针中有fops信息，可以告诉

操作系统相应的fops方法函数在那里可以找到。 

5，然后这时sys_write才会调用驱动程序中的write方法来对设备进行写的操作。 

其中1-3都是在用户空间进行的，4-5是在核心空间进行的。用户的write函数和操作系统

的write函数通过系统调用sys_write联系在了一起。 

注意： 

对于块设备来说，还存在写的模式的问题，这应该是由GNU C库来解决的，这里不予讨

论，因为我没有看过GNU C库的源代码。 

另外，这是一个测试版的文章，请各位朋友们多提意见和建议，非常感谢！ 

http://blog.csdn.net/lphpc/category/170686.aspx

1. 在嵌入式系统中，有时core dump直接从串口打印出来，结合objdump查找ra和epa地址，运用栈回溯，可以找到程序出错的地方。

2. 在一般Linux系统中，默认是不会产生core dump文件的，通过ulimit -c来查看core dump文件的大小，一般开始是0，可以设置core文件大小，ulimit -c 1024(kbytes单位)或者ulimit -c unlimited。

3. core dump文件输出设置，一般默认是当前目录，可以在/proc/sys/kernel中找到core-user-pid，通过

echo "1" > /proc/sys/kernel/core-user-pid使core文件名加上pid号，还可以用

mkdir -p /root/corefile

echo "/root/corefile/core-%e-%p-%t" > /proc/sys/kernel/core-pattern控制core文件保存位置和文件名格式。

以下是参数列表:
    %p - insert pid into filename 添加pid
    %u - insert current uid into filename 添加当前uid
    %g - insert current gid into filename 添加当前gid
    %s - insert signal that caused the coredump into the filename 添加导致产生core的信号
    %t - insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间
    %h - insert hostname where the coredump happened into filename 添加主机名
    %e - insert coredumping executable name into filename 添加命令名


4. 用gdb查看core文件:
下面我们可以在发生运行时信号引起的错误时发生core dump了.编译时加上-g
发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.
gdb [exec file] [core file]
如:
gdb ./test test.core
在进入gdb后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件行.

5. 给个例子

test.c

void a()

{

   char *p = NULL;

   printf("%d\n", *p);

}

int main()

{

    a();

    return 0;

}

编译 gcc -g -o test test.c

运行 ./test

报segmentation fault(core dump)

gdb ./test test.core如果生成的是test.core.

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/shanxiao528/archive/2010/05/11/5578743.aspx

共享内存 最快的IPC之一
消息队列
信号量 不同进程间 同一进程不同线程间的同步

Socket 不同机器上的进程间的通信

添加系统调用
添加系统模块

内存模型 分段 分页
逻辑地址->线性地址->物理地址

所有的段寄存器 段内偏移一样

页目录 页面 进程私有的
虚拟地址描述符表 虚拟内存管理 分配回收

物理内存管理

-----
进程
栈
堆
BSS
初始化的数据段
代码段

内核栈
控制块

进程Entry：
进程的虚拟地址空间->分区->分页
全局页目录pgd->pmd->page

线程同步
互斥锁
pthread_mutex_t
pthread_mutex_initializer
pthread-mutex_int
pthread_mutex_lock
pthread_mutex_unlock

条件变量
pthread_cond_t
pthread_cond_init
ptread_con_wait
调用之前和调用之后都是上锁的，一个条件变量关联一个互斥锁
函数内部实现机制
解锁
睡眠
上锁
pthead_cond_destroy
pthread_cond_broadcast
pthead_cond_signalh

所用软件：
VMware-workstation-6.0.0-45731.exe
Red Hat Linux 9

安装过程：
1.安装VMware-workstation-6.0.0-45731.exe
2.开启VMware.安装Linux.
  安装时可直接用硬盘iso文件.
  VMware=>VM=>Settings=>CD-RoM=>Use ISO image(选择iso位置,安装一张,在换另一个iso文件)
3.安装VMware后,会在XP上自动安装2个虚拟网卡:
  VMware Virtual Ethernet Adapter for VMnet1
  VMware Virtual Ethernet Adapter for VMnet8
  XP运行cmd=>ipconfig/all
  会查看到2个虚拟网卡及真实网卡的IP配置.
  因这2个虚拟网卡是装在XP系统上的，所以XP上可以Ping通.
4.此外,虚拟机上的Linux也有1个虚拟网卡,它的配置文件为
  /etc/sysconfig/network-scrīpts/ifcfg-eth0
5.我们可以把Linux的网关设置为XP系统虚拟网卡的IP地址,
  这样Linux就可以和XP通信了.
6.VMware=>VM=>Settings=>Ethemet=>Custom:Specific virtual network 选VMnet1(Host-only)
  将VMware Virtual Ethernet Adapter for VMnet1地址
  设置为: 192.168.0.1
          255.255.255.0
  修改ifcfg-eth0文件如下:
  DEVICE=eth0
  ōNBOOT=yes
  BOOTPROTO=none
  IPADDR=192.168.0.2
  NETMASK=255.255.255.0
  GATEWAY=192.168.0.1
  TYPE=Ethernet
  USERCTL=no
  PEERDNS=no
  NETWORK=192.168.0.0
  BROADCAST=192.168.0.255
  保存后更新下# service network restart

  也可以打开Linux开始=>系统设置=>网络,进行设置.
7.这时XP和Linux可以通信了.
  XP运行:ping 192.168.0.2  OK
8.此外SecureCRT是个不错的终端访问软件.可以装在XP上，访问Linux.
9.如果想让虚拟机的Linux也上网的话.
  可以在XP=>本地连接属性=>高级=>允许其他网络用户通过此计算机的Internet连接来连接
  (在家庭网络连接中选择VMware Network Adapter VMnet1)
  linux 主DNS 192.168.0.1

  这样就可以在虚拟Linux上网了. 

AIO 简介

Linux 异步 I/O 是 Linux 内核中提供的一个相当新的增强。它是 2.6 版本内核的一个标准特性，但是我们在 2.4 版本内核的补丁中也可以找到它。AIO 背后的基本思想是允许进程发起很多 I/O 操作，而不用阻塞或等待任何操作完成。稍后或在接收到 I/O 操作完成的通知时，进程就可以检索 I/O 操作的结果。

I/O 模型

在深入介绍 AIO API 之前，让我们先来探索一下 Linux 上可以使用的不同 I/O 模型。这并不是一个详尽的介绍，但是我们将试图介绍最常用的一些模型来解释它们与异步 I/O 之间的区别。图 1 给出了同步和异步模型，以及阻塞和非阻塞的模型。

每个 I/O 模型都有自己的使用模式，它们对于特定的应用程序都有自己的优点。本节将简要对其一一进行介绍。

同步阻塞 I/O

I/O 密集型与 CPU 密集型进程的比较 I/O 密集型进程所执行的 I/O 操作比执行的处理操作更多。CPU 密集型的进程所执行的处理操作比 I/O 操作更多。Linux 2.6 的调度器实际上更加偏爱 I/O 密集型的进程，因为它们通常会发起一个 I/O 操作，然后进行阻塞，这就意味着其他工作都可以在两者之间有效地交错进行。

最常用的一个模型是同步阻塞 I/O 模型。在这个模型中，用户空间的应用程序执行一个系统调用，这会导致应用程序阻塞。这意味着应用程序会一直阻塞，直到系统调用完成为止（数据传输完成或发生错误）。调用应用程序处于一种不再消费 CPU 而只是简单等待响应的状态，因此从处理的角度来看，这是非常有效的。

图 2 给出了传统的阻塞 I/O 模型，这也是目前应用程序中最为常用的一种模型。其行为非常容易理解，其用法对于典型的应用程序来说都非常有效。在调用 read 系统调用时，应用程序会阻塞并对内核进行上下文切换。然后会触发读操作，当响应返回时（从我们正在从中读取的设备中返回），数据就被移动到用户空间的缓冲区中。然后应用程序就会解除阻塞（read 调用返回）。

从应用程序的角度来说，read 调用会延续很长时间。实际上，在内核执行读操作和其他工作时，应用程序的确会被阻塞。

同步非阻塞 I/O

同步阻塞 I/O 的一种效率稍低的变种是同步非阻塞 I/O。在这种模型中，设备是以非阻塞的形式打开的。这意味着 I/O 操作不会立即完成，read 操作可能会返回一个错误代码，说明这个命令不能立即满足（EAGAIN 或 EWOULDBLOCK），如图 3 所示。

非阻塞的实现是 I/O 命令可能并不会立即满足，需要应用程序调用许多次来等待操作完成。这可能效率不高，因为在很多情况下，当内核执行这个命令时，应用程序必须要进行忙碌等待，直到数据可用为止，或者试图执行其他工作。正如图 3 所示的一样，这个方法可以引入 I/O 操作的延时，因为数据在内核中变为可用到用户调用 read 返回数据之间存在一定的间隔，这会导致整体数据吞吐量的降低。

异步阻塞 I/O

另外一个阻塞解决方案是带有阻塞通知的非阻塞 I/O。在这种模型中，配置的是非阻塞 I/O，然后使用阻塞 select 系统调用来确定一个 I/O 描述符何时有操作。使 select 调用非常有趣的是它可以用来为多个描述符提供通知，而不仅仅为一个描述符提供通知。对于每个提示符来说，我们可以请求这个描述符可以写数据、有读数据可用以及是否发生错误的通知。

select 调用的主要问题是它的效率不是非常高。尽管这是异步通知使用的一种方便模型，但是对于高性能的 I/O 操作来说不建议使用。

异步非阻塞 I/O（AIO）

最后，异步非阻塞 I/O 模型是一种处理与 I/O 重叠进行的模型。读请求会立即返回，说明 read 请求已经成功发起了。在后台完成读操作时，应用程序然后会执行其他处理操作。当 read 的响应到达时，就会产生一个信号或执行一个基于线程的回调函数来完成这次 I/O 处理过程。

在一个进程中为了执行多个 I/O 请求而对计算操作和 I/O 处理进行重叠处理的能力利用了处理速度与 I/O 速度之间的差异。当一个或多个 I/O 请求挂起时，CPU 可以执行其他任务；或者更为常见的是，在发起其他 I/O 的同时对已经完成的 I/O 进行操作。

下一节将深入介绍这种模型，探索这种模型使用的 API，然后展示几个命令。

回页首

异步 I/O 的动机

从前面 I/O 模型的分类中，我们可以看出 AIO 的动机。这种阻塞模型需要在 I/O 操作开始时阻塞应用程序。这意味着不可能同时重叠进行处理和 I/O 操作。同步非阻塞模型允许处理和 I/O 操作重叠进行，但是这需要应用程序根据重现的规则来检查 I/O 操作的状态。这样就剩下异步非阻塞 I/O 了，它允许处理和 I/O 操作重叠进行，包括 I/O 操作完成的通知。

除了需要阻塞之外，select 函数所提供的功能（异步阻塞 I/O）与 AIO 类似。不过，它是对通知事件进行阻塞，而不是对 I/O 调用进行阻塞。

回页首

Linux 上的 AIO 简介

本节将探索 Linux 的异步 I/O 模型，从而帮助我们理解如何在应用程序中使用这种技术。

在传统的 I/O 模型中，有一个使用惟一句柄标识的 I/O 通道。在 UNIX® 中，这些句柄是文件描述符（这对等同于文件、管道、套接字等等）。在阻塞 I/O 中，我们发起了一次传输操作，当传输操作完成或发生错误时，系统调用就会返回。

Linux 上的 AIO AIO 在 2.5 版本的内核中首次出现，现在已经是 2.6 版本的产品内核的一个标准特性了。

在异步非阻塞 I/O 中，我们可以同时发起多个传输操作。这需要每个传输操作都有惟一的上下文，这样我们才能在它们完成时区分到底是哪个传输操作完成了。在 AIO 中，这是一个 aiocb（AIO I/O Control Block）结构。这个结构包含了有关传输的所有信息，包括为数据准备的用户缓冲区。在产生 I/O （称为完成）通知时，aiocb 结构就被用来惟一标识所完成的 I/O 操作。这个 API 的展示显示了如何使用它。

回页首

AIO API

AIO 接口的 API 非常简单，但是它为数据传输提供了必需的功能，并给出了两个不同的通知模型。表 1 给出了 AIO 的接口函数，本节稍后会更详细进行介绍。

每个 API 函数都使用 aiocb 结构开始或检查。这个结构有很多元素，但是清单 1 仅仅给出了需要（或可以）使用的元素。

            struct aiocb {
            int aio_fildes;               // File Descriptor
            int aio_lio_opcode;           // Valid only for lio_listio (r/w/nop)
            volatile void *aio_buf;       // Data Buffer
            size_t aio_nbytes;            // Number of Bytes in Data Buffer
            struct sigevent aio_sigevent; // Notification Structure
            /* Internal fields */
            ...
            };
            

sigevent 结构告诉 AIO 在 I/O 操作完成时应该执行什么操作。我们将在 AIO 的展示中对这个结构进行探索。现在我们将展示各个 AIO 的 API 函数是如何工作的，以及我们应该如何使用它们。

aio_read

aio_read 函数请求对一个有效的文件描述符进行异步读操作。这个文件描述符可以表示一个文件、套接字甚至管道。aio_read 函数的原型如下：

int aio_read( struct aiocb *aiocbp );
            

aio_read 函数在请求进行排队之后会立即返回。如果执行成功，返回值就为 0；如果出现错误，返回值就为 -1，并设置 errno 的值。

要执行读操作，应用程序必须对 aiocb 结构进行初始化。下面这个简短的例子就展示了如何填充 aiocb 请求结构，并使用 aio_read 来执行异步读请求（现在暂时忽略通知）操作。它还展示了 aio_error 的用法，不过我们将稍后再作解释。

            #include <aio.h>
            ...
            int fd, ret;
            struct aiocb my_aiocb;
            fd = open( "file.txt", O_RDONLY );
            if (fd < 0) perror("open");
            /* Zero out the aiocb structure (recommended) */
            bzero( (char *)&my_aiocb, sizeof(struct aiocb) );
            /* Allocate a data buffer for the aiocb request */
            my_aiocb.aio_buf = malloc(BUFSIZE+1);
            if (!my_aiocb.aio_buf) perror("malloc");
            /* Initialize the necessary fields in the aiocb */
            my_aiocb.aio_fildes = fd;
            my_aiocb.aio_nbytes = BUFSIZE;
            my_aiocb.aio_offset = 0;
            ret = aio_read( &my_aiocb );
            if (ret < 0) perror("aio_read");
            while ( aio_error( &my_aiocb ) == EINPROGRESS ) ;
            if ((ret = aio_return( &my_iocb )) > 0) {
            /* got ret bytes on the read */
            } else {
            /* read failed, consult errno */
            }
            

在清单 2 中，在打开要从中读取数据的文件之后，我们就清空了 aiocb 结构，然后分配一个数据缓冲区。并将对这个数据缓冲区的引用放到 aio_buf 中。然后，我们将 aio_nbytes 初始化成缓冲区的大小。并将 aio_offset 设置成 0（该文件中的第一个偏移量）。我们将 aio_fildes 设置为从中读取数据的文件描述符。在设置这些域之后，就调用 aio_read 请求进行读操作。我们然后可以调用 aio_error 来确定 aio_read 的状态。只要状态是 EINPROGRESS，就一直忙碌等待，直到状态发生变化为止。现在，请求可能成功，也可能失败。

使用 AIO 接口来编译程序 我们可以在 aio.h 头文件中找到函数原型和其他需要的符号。在编译使用这种接口的程序时，我们必须使用 POSIX 实时扩展库（librt）。

注意使用这个 API 与标准的库函数从文件中读取内容是非常相似的。除了 aio_read 的一些异步特性之外，另外一个区别是读操作偏移量的设置。在传统的 read 调用中，偏移量是在文件描述符上下文中进行维护的。对于每个读操作来说，偏移量都需要进行更新，这样后续的读操作才能对下一块数据进行寻址。对于异步 I/O 操作来说这是不可能的，因为我们可以同时执行很多读请求，因此必须为每个特定的读请求都指定偏移量。

aio_error

aio_error 函数被用来确定请求的状态。其原型如下：

int aio_error( struct aiocb *aiocbp );
            

这个函数可以返回以下内容：

• EINPROGRESS，说明请求尚未完成
• ECANCELLED，说明请求被应用程序取消了
• -1，说明发生了错误，具体错误原因可以查阅 errno

aio_return

异步 I/O 和标准块 I/O 之间的另外一个区别是我们不能立即访问这个函数的返回状态，因为我们并没有阻塞在 read 调用上。在标准的 read 调用中，返回状态是在该函数返回时提供的。但是在异步 I/O 中，我们要使用 aio_return 函数。这个函数的原型如下：

ssize_t aio_return( struct aiocb *aiocbp );
            

只有在 aio_error 调用确定请求已经完成（可能成功，也可能发生了错误）之后，才会调用这个函数。aio_return 的返回值就等价于同步情况中 read 或 write 系统调用的返回值（所传输的字节数，如果发生错误，返回值就为 -1）。

aio_write

aio_write 函数用来请求一个异步写操作。其函数原型如下：

int aio_write( struct aiocb *aiocbp );
            

aio_write 函数会立即返回，说明请求已经进行排队（成功时返回值为 0，失败时返回值为 -1，并相应地设置 errno）。

这与 read 系统调用类似，但是有一点不一样的行为需要注意。回想一下对于 read 调用来说，要使用的偏移量是非常重要的。然而，对于 write 来说，这个偏移量只有在没有设置 O_APPEND 选项的文件上下文中才会非常重要。如果设置了 O_APPEND，那么这个偏移量就会被忽略，数据都会被附加到文件的末尾。否则，aio_offset 域就确定了数据在要写入的文件中的偏移量。

aio_suspend

我们可以使用 aio_suspend 函数来挂起（或阻塞）调用进程，直到异步请求完成为止，此时会产生一个信号，或者发生其他超时操作。调用者提供了一个 aiocb 引用列表，其中任何一个完成都会导致 aio_suspend 返回。 aio_suspend 的函数原型如下：

int aio_suspend( const struct aiocb *const cblist[],
            int n, const struct timespec *timeout );
            

aio_suspend 的使用非常简单。我们要提供一个 aiocb 引用列表。如果任何一个完成了，这个调用就会返回 0。否则就会返回 -1，说明发生了错误。请参看清单 3。

            struct aioct *cblist[MAX_LIST]
            /* Clear the list. */
            bzero( (char *)cblist, sizeof(cblist) );
            /* Load one or more references into the list */
            cblist[0] = &my_aiocb;
            ret = aio_read( &my_aiocb );
            ret = aio_suspend( cblist, MAX_LIST, NULL );
            

注意，aio_suspend 的第二个参数是 cblist 中元素的个数，而不是 aiocb 引用的个数。cblist 中任何 NULL 元素都会被 aio_suspend 忽略。

如果为 aio_suspend 提供了超时，而超时情况的确发生了，那么它就会返回 -1，errno 中会包含 EAGAIN。

aio_cancel

aio_cancel 函数允许我们取消对某个文件描述符执行的一个或所有 I/O 请求。其原型如下：

int aio_cancel( int fd, struct aiocb *aiocbp );
            

要取消一个请求，我们需要提供文件描述符和 aiocb 引用。如果这个请求被成功取消了，那么这个函数就会返回 AIO_CANCELED。如果请求完成了，这个函数就会返回 AIO_NOTCANCELED。

要取消对某个给定文件描述符的所有请求，我们需要提供这个文件的描述符，以及一个对 aiocbp 的 NULL 引用。如果所有的请求都取消了，这个函数就会返回 AIO_CANCELED；如果至少有一个请求没有被取消，那么这个函数就会返回 AIO_NOT_CANCELED；如果没有一个请求可以被取消，那么这个函数就会返回 AIO_ALLDONE。我们然后可以使用 aio_error 来验证每个 AIO 请求。如果这个请求已经被取消了，那么 aio_error 就会返回 -1，并且 errno 会被设置为 ECANCELED。

lio_listio

最后，AIO 提供了一种方法使用 lio_listio API 函数同时发起多个传输。这个函数非常重要，因为这意味着我们可以在一个系统调用（一次内核上下文切换）中启动大量的 I/O 操作。从性能的角度来看，这非常重要，因此值得我们花点时间探索一下。lio_listio API 函数的原型如下：

int lio_listio( int mode, struct aiocb *list[], int nent,
            struct sigevent *sig );
            

mode 参数可以是 LIO_WAIT 或 LIO_NOWAIT。LIO_WAIT 会阻塞这个调用，直到所有的 I/O 都完成为止。在操作进行排队之后，LIO_NOWAIT 就会返回。list 是一个 aiocb 引用的列表，最大元素的个数是由 nent 定义的。注意 list 的元素可以为 NULL，lio_listio 会将其忽略。sigevent 引用定义了在所有 I/O 操作都完成时产生信号的方法。

对于 lio_listio 的请求与传统的 read 或 write 请求在必须指定的操作方面稍有不同，如清单 4 所示。

            struct aiocb aiocb1, aiocb2;
            struct aiocb *list[MAX_LIST];
            ...
            /* Prepare the first aiocb */
            aiocb1.aio_fildes = fd;
            aiocb1.aio_buf = malloc( BUFSIZE+1 );
            aiocb1.aio_nbytes = BUFSIZE;
            aiocb1.aio_offset = next_offset;
            aiocb1.aio_lio_opcode = LIO_READ;
            ...
            bzero( (char *)list, sizeof(list) );
            list[0] = &aiocb1;
            list[1] = &aiocb2;
            ret = lio_listio( LIO_WAIT, list, MAX_LIST, NULL );
            

对于读操作来说，aio_lio_opcode 域的值为 LIO_READ。对于写操作来说，我们要使用 LIO_WRITE，不过 LIO_NOP 对于不执行操作来说也是有效的。

回页首

AIO 通知

现在我们已经看过了可用的 AIO 函数，本节将深入介绍对异步通知可以使用的方法。我们将通过信号和函数回调来探索异步函数的通知机制。

使用信号进行异步通知

使用信号进行进程间通信（IPC）是 UNIX 中的一种传统机制，AIO 也可以支持这种机制。在这种范例中，应用程序需要定义信号处理程序，在产生指定的信号时就会调用这个处理程序。应用程序然后配置一个异步请求将在请求完成时产生一个信号。作为信号上下文的一部分，特定的 aiocb 请求被提供用来记录多个可能会出现的请求。清单 5 展示了这种通知方法。

            void setup_io( ... )
            {
            int fd;
            struct sigaction sig_act;
            struct aiocb my_aiocb;
            ...
            /* Set up the signal handler */
            sigemptyset(&sig_act.sa_mask);
            sig_act.sa_flags = SA_SIGINFO;
            sig_act.sa_sigaction = aio_completion_handler;
            /* Set up the AIO request */
            bzero( (char *)&my_aiocb, sizeof(struct aiocb) );
            my_aiocb.aio_fildes = fd;
            my_aiocb.aio_buf = malloc(BUF_SIZE+1);
            my_aiocb.aio_nbytes = BUF_SIZE;
            my_aiocb.aio_offset = next_offset;
            /* Link the AIO request with the Signal Handler */
            my_aiocb.aio_sigevent.sigev_notify = SIGEV_SIGNAL;
            my_aiocb.aio_sigevent.sigev_signo = SIGIO;
            my_aiocb.aio_sigevent.sigev_value.sival_ptr = &my_aiocb;
            /* Map the Signal to the Signal Handler */
            ret = sigaction( SIGIO, &sig_act, NULL );
            ...
            ret = aio_read( &my_aiocb );
            }
            void aio_completion_handler( int signo, siginfo_t *info, void *context )
            {
            struct aiocb *req;
            /* Ensure it's our signal */
            if (info->si_signo == SIGIO) {
            req = (struct aiocb *)info->si_value.sival_ptr;
            /* Did the request complete? */
            if (aio_error( req ) == 0) {
            /* Request completed successfully, get the return status */
            ret = aio_return( req );
            }
            }
            return;
            }
            

在清单 5 中，我们在 aio_completion_handler 函数中设置信号处理程序来捕获 SIGIO 信号。然后初始化 aio_sigevent 结构产生 SIGIO 信号来进行通知（这是通过 sigev_notify 中的 SIGEV_SIGNAL 定义来指定的）。当读操作完成时，信号处理程序就从该信号的 si_value 结构中提取出 aiocb，并检查错误状态和返回状态来确定 I/O 操作是否完成。

对于性能来说，这个处理程序也是通过请求下一次异步传输而继续进行 I/O 操作的理想地方。采用这种方式，在一次数据传输完成时，我们就可以立即开始下一次数据传输操作。

使用回调函数进行异步通知

另外一种通知方式是系统回调函数。这种机制不会为通知而产生一个信号，而是会调用用户空间的一个函数来实现通知功能。我们在 sigevent 结构中设置了对 aiocb 的引用，从而可以惟一标识正在完成的特定请求。请参看清单 6。

            void setup_io( ... )
            {
            int fd;
            struct aiocb my_aiocb;
            ...
            /* Set up the AIO request */
            bzero( (char *)&my_aiocb, sizeof(struct aiocb) );
            my_aiocb.aio_fildes = fd;
            my_aiocb.aio_buf = malloc(BUF_SIZE+1);
            my_aiocb.aio_nbytes = BUF_SIZE;
            my_aiocb.aio_offset = next_offset;
            /* Link the AIO request with a thread callback */
            my_aiocb.aio_sigevent.sigev_notify = SIGEV_THREAD;
            my_aiocb.aio_sigevent.notify_function = aio_completion_handler;
            my_aiocb.aio_sigevent.notify_attributes = NULL;
            my_aiocb.aio_sigevent.sigev_value.sival_ptr = &my_aiocb;
            ...
            ret = aio_read( &my_aiocb );
            }
            void aio_completion_handler( sigval_t sigval )
            {
            struct aiocb *req;
            req = (struct aiocb *)sigval.sival_ptr;
            /* Did the request complete? */
            if (aio_error( req ) == 0) {
            /* Request completed successfully, get the return status */
            ret = aio_return( req );
            }
            return;
            }
            

在清单 6 中，在创建自己的 aiocb 请求之后，我们使用 SIGEV_THREAD 请求了一个线程回调函数来作为通知方法。然后我们将指定特定的通知处理程序，并将要传输的上下文加载到处理程序中（在这种情况中，是个对 aiocb 请求自己的引用）。在这个处理程序中，我们简单地引用到达的 sigval 指针并使用 AIO 函数来验证请求已经完成。

回页首

对 AIO 进行系统优化

proc 文件系统包含了两个虚拟文件，它们可以用来对异步 I/O 的性能进行优化：

• /proc/sys/fs/aio-nr 文件提供了系统范围异步 I/O 请求现在的数目。
• /proc/sys/fs/aio-max-nr 文件是所允许的并发请求的最大个数。最大个数通常是 64KB，这对于大部分应用程序来说都已经足够了。

回页首

结束语

使用异步 I/O 可以帮助我们构建 I/O 速度更快、效率更高的应用程序。如果我们的应用程序可以对处理和 I/O 操作重叠进行，那么 AIO 就可以帮助我们构建可以更高效地使用可用 CPU 资源的应用程序。尽管这种 I/O 模型与在大部分 Linux 应用程序中使用的传统阻塞模式都不同，但是异步通知模型在概念上来说却非常简单，可以简化我们的设计。

bitsCN.nET*中国网管博客

bbs.bitsCN.com