首先,先略微了解系统调用的概念:
系统调用,英文名system call,每一个操作系统都在内核里有一些内建的函数库,这些函数能够用来完毕一些系统系统调用把应用程序的请求传给内核,调用对应的的内核函数完毕所需的处理,将处理结果返回给应用程序,假设没有系统调用和内核函数,用户将不能编写大型应用程序,及别的功能,这些函数集合起来就叫做程序接口或应用编程接口(ApplicationProgramming
Interface,API),我们要在这个系统上编写各种应用程序,就是通过这个API接口来调用系统内核里面的函数。
假设没有系统调用,那么应用程序就失去内核的支持。
如今。再聊不带缓存的I/O操作:
linix对IO文件的操作分为不带缓存的IO操作和标准IO操作(即带缓存),刚開始。要明白下面几点:
1:不带缓存。不是直接对磁盘文件进行读取操作,像read()和write()函数,它们都属于系统调用,仅仅只是在用户层没有缓存,所以叫做无缓存IO,但对于内核来说。还是进行了缓存。仅仅是用户层看不到罢了。假设这一点看不懂。请看第二点;
2:带不带缓存是相对来说的,假设你要写入数据到文件上时(就是写入磁盘上),内核先将数据写入到内核中所设的缓冲储存器。假如这个缓冲储存器的长度是100个字节。你调用系统函:
ssize_t write (int fd,const void * buf,size_t count);
写操作时,设每次写入长度count=10个字节,那么你几要调用10次这个函数才干把这个缓冲区写满。此时数据还是在缓冲区,并没有写入到磁盘。缓冲区满时才进行实际上的IO操作,把数据写入到磁盘上,所以上面说的“不带缓存不是就没有缓存直写进磁盘”就是这个意思。
那么。既然不带缓存的操作实际在内核是有缓存器的。那带缓存的IO操作又是怎么回事呢?
带缓存IO也叫标准IO,符合ANSIC 的标准IO处理,不依赖系统内核,所以移植性强,我们使用标准IO操作非常多时候是为了降低对read()和write()的系统调用次数。带缓存IO事实上就是在用户层再建立一个缓存区,这个缓存区的分配和优化长度等细节都是标准IO库代你处理好了,不用去担心。还是用上面那个样例说明这个操作过程:
上面说要写数据到文件上。内核缓存(注意这个不是用户层缓存区)区长度是100字节。我们调用不带缓存的IO函数write()就要调用10次,这样系统效率低,如今我们在用户层建立还有一个缓存区(用户层缓存区或者叫流缓存),如果流缓存的长度是50字节,我们用标准C库函数的fwrite()将数据写入到这个流缓存区里面,流缓存区满50字节后在进入内核缓存区,此时再调用系统函数write()将数据写入到文件(实质是磁盘)上,看到这里。你用该明确一点,标准IO操作fwrite()最后还是要掉用无缓存IO操作write,这里进行了两次调用fwrite()写100字节也就是进行两次系统调用write()。
假设看到这里还没有一点眉目的话。那就比較麻烦了,希望以下两条总结可以帮上忙:
无缓存IO操作数据流向路径:数据——内核缓存区——磁盘
标准IO操作数据流向路径:数据——流缓存区——内核缓存区——磁盘
以下是一个网友的见解,以供參考:
不带缓存的I/O对文件描写叙述符操作。以下带缓存的I/O是针对流的。
标准I/O库就是带缓存的I/O,它由ANSI C标准说明。当然,标准I/O终于都会调用上面的I/O例程。
标准I/O库取代用户处理非常多细节。比方缓存分配、以优化长度运行I/O等。
标准I/O提供缓存的目的就是降低调用read和write的次数,它对每一个I/O流自己主动进行缓存管理(标准I/O函数通常调用malloc来分配缓存)。
它提供了三种类型的缓存:
1) 全缓存。当填满标准I/O缓存后才运行I/O操作。
磁盘上的文件一般是全缓存的。
2) 行缓存。当输入输出遇到新行符或缓存满时,才由标准I/O库运行实际I/O操作。stdin、stdout一般是行缓存的。
3) 无缓存。相当于read、write了。
stderr一般是无缓存的。由于它必须尽快输出。
一般而言。由系统选择缓存的长度。并自己主动分配。标准I/O库在关闭流的时候自己主动释放缓存。
在标准I / O库中。一个效率不高的不足之处是须要复制的数据量。当使用每次一行函数fgets和fputs时。通常须要复制两次数据:一次是在内核和标准I / O缓存之间(当调用read和write时)。第二次是在标准I / O缓存(通常系统分配和管理)和用户程序中的行缓存(fgets的參数就须要一个用户行缓存指针)之间。
无论上面讲的究竟懂没懂,记住一点:
使用标准I / O例程的一个长处是无需考虑缓存及最佳I / O长度的选择,而且它并不比直接调用read、write慢多少。
带缓存的文件操作是标准C 库的实现,第一次调用带缓存的文件操作函数时标准库会自己主动分配内存并且读出一段固定大小的内容存储在缓存中。所以以后每次的读写操作并非针对硬盘上的文件直接进行的,而是针对内存中的缓存的。何时从硬盘中读取文件或者向硬盘中写入文件有标准库的机制控制。
不带缓存的文件操作通常都是系统提供的系统调用。更加低级,直接从硬盘中读取和写入文件,因为 IO瓶颈的原因,速度并不如意。并且原子操作须要程序猿自己保证,但使用得当的话效率并不差。另外标准库中的带缓存文件IO 是调用系统提供的不带缓存IO实现的。
这里为了说明标准I/O的工作原理,借用了glibc中标准I/O实现的细节,所以代码多是不可移植的.
1. buffered I/O, 即标准I/O
首先,要明白,unbuffered
I/O仅仅是相对于buffered I/O,即标准I/O来说的.
而不是说unbuffered I/O读写磁盘时不用缓冲.实际上,内核是存在快速缓冲区来进行
真正的磁盘读写的,只是这里要讨论的buffer跟内核中的缓冲区无关.
buffered I/O的目的是什么呢?
非常easy,buffered I/O的目的就是为了提高效率.
请明白一个关系,那就是,
buffered I/O库函数(fread, fwrite等,用户空间)<----call---> unbuffered
I/O系统调用(read,write等,内核空间)<------->读写磁盘
buffered I/O库函数都是调用相关的unbuffered I/O系统调用来实现的,他们并不直接读写磁盘.
那么,效率的提高从何而来呢?
注意到,buffered I/O中都是库函数,而unbufferedI/O中为系统调用,使用库函数的效率是高于使用系统调用的.
buffered I/O就是通过尽可能的少使用系统调用来提高效率的.
它的基本方法是,在用户进程空间维护一块缓冲区,第一次读(库函数)的时候用read(系统调用)多从内核读出一些数据,
下次在要读(库函数)数据的时候,先从该缓冲区读,而不用进行再次read(系统调用)了.
相同,写的时候,先将数据写入(库函数)一个缓冲区,多次以后,在集中进行一次write(系统调用),写入内核空间.
buffered I/O中的fgets, puts, fread, fwrite等和unbufferedI/O中的read,write等就是调用和被调用的关系
以下是一个利用buffered I/O读取数据的样例:
#include <stdlib.h> |
buffered I/O中的"buffer"究竟是指什么呢?
这个buffer在什么地方呢?
FILE是什么呢?它的空间是怎么分配的呢?
要弄清楚这些问题,就要看看FILE是怎样定义和运作的了.
(特别说明,在平时敲代码时,不用也不要关心FILE是怎样定义和运作的,最好不要直接操作
它,这里使用它,仅仅是为了说明buffered
IO)
以下的这个是glibc给出的FILE的定义,它是实现相关的,别的平台定义方式不同.
struct _IO_FILE { |
上面的定义中有三组重要的字段:
1.
char* _IO_read_ptr;
char* _IO_read_end;
char* _IO_read_base;
2.
char* _IO_write_base;
char* _IO_write_ptr;
char* _IO_write_end;
3.
char* _IO_buf_base;
char* _IO_buf_end;
当中,
_IO_read_base 指向"读缓冲区"
_IO_read_end 指向"读缓冲区"的末尾
_IO_read_end - _IO_read_base "读缓冲区"的长度
_IO_write_base 指向"写缓冲区"
_IO_write_end 指向"写缓冲区"的末尾
_IO_write_end - _IO_write_base "写缓冲区"的长度
_IO_buf_base 指向"缓冲区"
_IO_buf_end 指向"缓冲区"的末尾
_IO_buf_end - _IO_buf_base "缓冲区"的长度
上面的定义貌似给出了3个缓冲区,实际上上面的_IO_read_base,
_IO_write_base, _IO_buf_base都指向了同一个缓冲区.
这个缓冲区跟上面程序中的char buf[5];没有不论什么关系.
他们在第一次buffered I/O操作时由库函数自己主动申请空间,最后由对应库函数负责释放.
(再次声明,这里仅仅是glibc的实现,别的实现可能会不同,后面就不再强调了)
请看以下的程序(这里给的是stdin,行缓冲的样例):
#include <stdlib.h> |
能够看到,在读操作之前,myfile的缓冲区是没有被分配的,在一次读之后,myfile的缓冲区才被分配.
这个缓冲区既不是内核中的缓冲区,也不是用户分配的缓冲区,而是实用户进程空间中的由buffered
I/O系统负责维护的缓冲区.
(当然,用户能够能够维护该缓冲区,这里不做讨论了)
上面的样例仅仅是说明了buffered I/O缓冲区的存在,以下从全缓冲,行缓冲和无缓冲3个方面看一下buffered
I/O
是怎样工作的.
1.1. 全缓冲
以下是APUE上的原话:
全缓冲"在填满标准I/O缓冲区后才进行实际的I/O操作.对于驻留在磁盘上的文件一般是由标准I/O库实施全缓冲的"
书中这里"实际的I/O操作"实际上easy引起误导,这里并非读写磁盘,而应该是进行read或write的系统调用
以下两个样例会说明这个问题
#include <stdlib.h> |
上面提到的bbb.txt文件的内容是由非常多行的"123456789"组成
上例中,fgets(buf, 5, myfile); 只读4个字符,可是,缓冲区已被写满,
可是_IO_read_ptr却向前移动了5位,下次再次调用读操作时,
仅仅要要读的位数不超过myfile->_IO_read_end - myfile->_IO_read_ptr
那么就不须要再次调用系统调用read,仅仅要将数据从myfile的缓冲区复制到
buf就可以(从myfile->_IO_read_ptr開始拷贝)
全缓冲读的时候,
_IO_read_base始终指向缓冲区的開始
_IO_read_end始终指向已从内核读入缓冲区的字符的下一个
(对全缓冲来说,buffered I/O读每次都试图都将缓冲区读满)
_IO_read_ptr始终指向缓冲区中已被用户读走的字符的下一个
(_IO_read_end < (_IO_buf_base-_IO_buf_end)) && (_IO_read_ptr ==_IO_read_end)时则已经到达文件末尾
当中_IO_buf_base-_IO_buf_end是缓冲区的长度
一般大体的工作情景为:
第一次fgets(或其它的)时,标准I/O会调用read将缓冲区充满,下一次fgets不调用read而是直接从该缓冲区中拷贝数据,直到
缓冲区的中剩余的数据不够时,再次调用read.在这个过程中,_IO_read_ptr就是用来记录缓冲区中哪些数据是已读的,
哪些数据是未读的.
#include <stdlib.h> |
上面这个是关于全缓冲写的样例.
全缓冲时,仅仅有当标准I/O自己主动flush(比方当缓冲区已满时)或者手工调用fflush时,
标准I/O才会调用一次write系统调用.
样例中,fwrite(buf+i, 1, 512, myfile);这一句仅仅是将buf+i接下来的512个字节
写入缓冲区,因为缓冲区未满,标准I/O并未调用write.
此时,myfile->_IO_write_ptr = myfile->_IO_write_base;会导致标准I/O觉得
没有数据写入缓冲区,所以永远不会调用write,这样aaa.txt文件得不到写入.
凝视掉myfile->_IO_write_ptr = myfile->_IO_write_base;前后,看看效果
全缓冲写的时候:
_IO_write_base始终指向缓冲区的開始
_IO_write_end全缓冲的时候,始终指向缓冲区的最后一个字符的下一个
(对全缓冲来说,buffered I/O写总是试图在缓冲区写满之后,再系统调用write)
_IO_write_ptr始终指向缓冲区中已被用户写入的字符的下一个
flush的时候,将_IO_write_base和_IO_write_ptr之间的字符通过系统调用write写入内核
1.2. 行缓冲
以下是APUE上的原话:
行缓冲"当输入输出中遇到换行符时,标准I/O库运行I/O操作."
书中这里"运行O操作"也easy引起误导,这里不是读写磁盘,而应该是进行read或write的系统调用
以下两个样例会说明这个问题
第一个样例能够用来说明以下这篇帖子的问题
http://bbs.chinaunix.net/viewthread.php?tid=954547
#include <stdlib.h>
//而非只上面须要的个字符 |
上例中, fgets(buf, 5,stdin); 只须要4个字符,可是,输入行中的其它数据也被写入缓冲区,
可是_IO_read_ptr向前移动了5位,下次再次调用fgets操作时,就不须要再次调用系统调用read,
仅仅要将数据从stdin的缓冲区复制到buf2就可以(从stdin->_IO_read_ptr開始拷贝)
stdin->_IO_read_ptr = stdin->_IO_read_end;会导致标准I/O会觉得缓冲区已空,
再次fgets则须要再次调用read.比較一下将该句凝视掉前后的效果
行缓冲读的时候,
_IO_read_base始终指向缓冲区的開始
_IO_read_end始终指向已从内核读入缓冲区的字符的下一个
_IO_read_ptr始终指向缓冲区中已被用户读走的字符的下一个
(_IO_read_end < (_IO_buf_base-_IO_buf_end)) && (_IO_read_ptr ==_IO_read_end)时则已经到达文件末尾
当中_IO_buf_base-_IO_buf_end是缓冲区的长度
#include <stdlib.h> |
这个样例将将FILE结构中指针的变化写入的文件ccc.txt
执行后能够有兴趣的话,能够看看.
上面这个是关于行缓冲写的样例.
stdout->_IO_write_ptr = stdout->_IO_write_base;会使得标准I/O觉得
缓冲区是空的,从而没有不论什么输出.
能够将上面程序中的凝视分别去掉,看看执行结果
行缓冲时,以下3个条件之中的一个会导致缓冲区马上被flush
1. 缓冲区已满
2. 遇到一个换行符;比方将上面样例中buf[4]改为'
'时
3. 再次要求从内核中得到数据时;比方上面的程序加上getchar()会导致立即输出
行缓冲写的时候:
_IO_write_base始终指向缓冲区的開始
_IO_write_end始终指向缓冲区的開始
_IO_write_ptr始终指向缓冲区中已被用户写入的字符的下一个
flush的时候,将_IO_write_base和_IO_write_ptr之间的字符通过系统调用write写入内核
1.3. 无缓冲
无缓冲时,标准I/O不正确字符进行缓冲存储.典型代表是stderr
这里的无缓冲,并非指缓冲区大小为0,事实上,还是有缓冲的,大小为1
#include <stdlib.h> |
对无缓冲的流的每次读写操作都会引起系统调用
1.4 feof的问题
CU上已经有无数的帖子在探讨feof了,这里从缓冲区的角度去考察一下.
对于一个空文件,为什么要先读一下,才干用feof推断出该文件到了结尾了呢?
#include <stdlib.h> |
执行上面的程序,输入多于4个,少于13个字符,而且以连按两次ctrl+d为结束(不要按回车)
从上面的样例,能够看出,每当满足
(_IO_read_end < (_IO_buf_base-_IO_buf_end)) && (_IO_read_ptr ==_IO_read_end)
时,标准I/O则觉得已经到达文件末尾,feof(stdin)才会被设置
当中_IO_buf_base-_IO_buf_end是缓冲区的长度
也就是说,标准I/O是通过它的缓冲区来推断流是否要结束了的.
这就解释了为什么即使是一个空文件,标准I/O也须要读一次,才干使用feof推断释放为空
1.5. 其它说明
非常多新手有一个误解,就是fgets,
fputs代表行缓冲,fread,fwrite代表全缓冲 fgetc,
fputc代表无缓冲
等等.
事实上不是这种,是什么样的缓冲跟使用那个函数没有关系,
而跟你读写什么类型的文件有关系.
上面的样例中多次在全缓冲中使用fgets, fputs,而在行缓冲中使用fread,
fwrite
以下的是引至APUE的
实际上
ISO C要求:
1.当且仅当标准输入和标准输出并不涉及交互式设备时,他们才是全缓冲的
2.标准输出决不是全缓冲的.
非常多系统默认使用下列类型的标准:
1.标准输出是不带缓冲的.
2.如若是涉及终端设备的其它流,则他们是行缓冲的;否则是全缓冲的.
首先。先略微了解系统调用的概念:
系统调用,英文名system call,每一个操作系统都在内核里有一些内建的函数库。这些函数能够用来完毕一些系统系统调用把应用程序的请求传给内核,调用对应的的内核函数完毕所需的处理,将处理结果返回给应用程序。假设没有系统调用和内核函数,用户将不能编写大型应用程序,及别的功能。这些函数集合起来就叫做程序接口或应用编程接口(ApplicationProgramming
Interface,API),我们要在这个系统上编写各种应用程序。就是通过这个API接口来调用系统内核里面的函数。假设没有系统调用。那么应用程序就失去内核的支持。
如今,再聊不带缓存的I/O操作:
linix对IO文件的操作分为不带缓存的IO操作和标准IO操作(即带缓存)。刚開始,要明白下面几点:
1:不带缓存。不是直接对磁盘文件进行读取操作,像read()和write()函数。它们都属于系统调用,仅仅只是在用户层没有缓存。所以叫做无缓存IO,但对于内核来说。还是进行了缓存,仅仅是用户层看不到罢了。假设这一点看不懂。请看第二点;
2:带不带缓存是相对来说的。假设你要写入数据到文件上时(就是写入磁盘上),内核先将数据写入到内核中所设的缓冲储存器。假如这个缓冲储存器的长度是100个字节,你调用系统函:
ssize_t write (int fd,const void * buf,size_t count);
写操作时,设每次写入长度count=10个字节,那么你几要调用10次这个函数才干把这个缓冲区写满,此时数据还是在缓冲区,并没有写入到磁盘,缓冲区满时才进行实际上的IO操作,把数据写入到磁盘上,所以上面说的“不带缓存不是就没有缓存直写进磁盘”就是这个意思。
那么,既然不带缓存的操作实际在内核是有缓存器的。那带缓存的IO操作又是怎么回事呢?
带缓存IO也叫标准IO,符合ANSIC 的标准IO处理。不依赖系统内核,所以移植性强,我们使用标准IO操作非常多时候是为了降低对read()和write()的系统调用次数。带缓存IO事实上就是在用户层再建立一个缓存区,这个缓存区的分配和优化长度等细节都是标准IO库代你处理好了。不用去担心,还是用上面那个样例说明这个操作过程:
上面说要写数据到文件上,内核缓存(注意这个不是用户层缓存区)区长度是100字节,我们调用不带缓存的IO函数write()就要调用10次。这样系统效率低。如今我们在用户层建立还有一个缓存区(用户层缓存区或者叫流缓存),如果流缓存的长度是50字节。我们用标准C库函数的fwrite()将数据写入到这个流缓存区里面。流缓存区满50字节后在进入内核缓存区。此时再调用系统函数write()将数据写入到文件(实质是磁盘)上,看到这里。你用该明确一点,标准IO操作fwrite()最后还是要掉用无缓存IO操作write,这里进行了两次调用fwrite()写100字节也就是进行两次系统调用write()。
假设看到这里还没有一点眉目的话,那就比較麻烦了,希望以下两条总结可以帮上忙:
无缓存IO操作数据流向路径:数据——内核缓存区——磁盘
标准IO操作数据流向路径:数据——流缓存区——内核缓存区——磁盘
以下是一个网友的见解,以供參考:
不带缓存的I/O对文件描写叙述符操作,以下带缓存的I/O是针对流的。
标准I/O库就是带缓存的I/O,它由ANSI C标准说明。当然,标准I/O终于都会调用上面的I/O例程。标准I/O库取代用户处理非常多细节,比方缓存分配、以优化长度运行I/O等。
标准I/O提供缓存的目的就是降低调用read和write的次数,它对每一个I/O流自己主动进行缓存管理(标准I/O函数通常调用malloc来分配缓存)。它提供了三种类型的缓存:
1) 全缓存。当填满标准I/O缓存后才运行I/O操作。磁盘上的文件一般是全缓存的。
2) 行缓存。当输入输出遇到新行符或缓存满时,才由标准I/O库运行实际I/O操作。
stdin、stdout一般是行缓存的。
3) 无缓存。
相当于read、write了。stderr一般是无缓存的。由于它必须尽快输出。
一般而言。由系统选择缓存的长度,并自己主动分配。标准I/O库在关闭流的时候自己主动释放缓存。
在标准I / O库中。一个效率不高的不足之处是须要复制的数据量。
当使用每次一行函数fgets和fputs时,通常须要复制两次数据:一次是在内核和标准I / O缓存之间(当调用read和write时),第二次是在标准I / O缓存(通常系统分配和管理)和用户程序中的行缓存(fgets的參数就须要一个用户行缓存指针)之间。
无论上面讲的究竟懂没懂,记住一点:
使用标准I / O例程的一个长处是无需考虑缓存及最佳I / O长度的选择,而且它并不比直接调用read、write慢多少。
带缓存的文件操作是标准C 库的实现。第一次调用带缓存的文件操作函数时标准库会自己主动分配内存并且读出一段固定大小的内容存储在缓存中。所以以后每次的读写操作并非针对硬盘上的文件直接进行的,而是针对内存中的缓存的。何时从硬盘中读取文件或者向硬盘中写入文件有标准库的机制控制。不带缓存的文件操作通常都是系统提供的系统调用,更加低级。直接从硬盘中读取和写入文件,因为 IO瓶颈的原因,速度并不如意,并且原子操作须要程序猿自己保证,但使用得当的话效率并不差。另外标准库中的带缓存文件IO 是调用系统提供的不带缓存IO实现的。
这里为了说明标准I/O的工作原理,借用了glibc中标准I/O实现的细节,所以代码多是不可移植的.
1. buffered I/O, 即标准I/O
首先,要明白,unbuffered
I/O仅仅是相对于buffered I/O,即标准I/O来说的.
而不是说unbuffered I/O读写磁盘时不用缓冲.实际上,内核是存在快速缓冲区来进行
真正的磁盘读写的,只是这里要讨论的buffer跟内核中的缓冲区无关.
buffered I/O的目的是什么呢?
非常easy,buffered I/O的目的就是为了提高效率.
请明白一个关系,那就是,
buffered I/O库函数(fread, fwrite等,用户空间)<----call---> unbuffered
I/O系统调用(read,write等,内核空间)<------->读写磁盘
buffered I/O库函数都是调用相关的unbuffered I/O系统调用来实现的,他们并不直接读写磁盘.
那么,效率的提高从何而来呢?
注意到,buffered I/O中都是库函数,而unbufferedI/O中为系统调用,使用库函数的效率是高于使用系统调用的.
buffered I/O就是通过尽可能的少使用系统调用来提高效率的.
它的基本方法是,在用户进程空间维护一块缓冲区,第一次读(库函数)的时候用read(系统调用)多从内核读出一些数据,
下次在要读(库函数)数据的时候,先从该缓冲区读,而不用进行再次read(系统调用)了.
相同,写的时候,先将数据写入(库函数)一个缓冲区,多次以后,在集中进行一次write(系统调用),写入内核空间.
buffered I/O中的fgets, puts, fread, fwrite等和unbufferedI/O中的read,write等就是调用和被调用的关系
以下是一个利用buffered I/O读取数据的样例:
#include <stdlib.h> |
buffered I/O中的"buffer"究竟是指什么呢?
这个buffer在什么地方呢?
FILE是什么呢?它的空间是怎么分配的呢?
要弄清楚这些问题,就要看看FILE是怎样定义和运作的了.
(特别说明,在平时敲代码时,不用也不要关心FILE是怎样定义和运作的,最好不要直接操作
它,这里使用它,仅仅是为了说明buffered
IO)
以下的这个是glibc给出的FILE的定义,它是实现相关的,别的平台定义方式不同.
struct _IO_FILE { |
上面的定义中有三组重要的字段:
1.
char* _IO_read_ptr;
char* _IO_read_end;
char* _IO_read_base;
2.
char* _IO_write_base;
char* _IO_write_ptr;
char* _IO_write_end;
3.
char* _IO_buf_base;
char* _IO_buf_end;
当中,
_IO_read_base 指向"读缓冲区"
_IO_read_end 指向"读缓冲区"的末尾
_IO_read_end - _IO_read_base "读缓冲区"的长度
_IO_write_base 指向"写缓冲区"
_IO_write_end 指向"写缓冲区"的末尾
_IO_write_end - _IO_write_base "写缓冲区"的长度
_IO_buf_base 指向"缓冲区"
_IO_buf_end 指向"缓冲区"的末尾
_IO_buf_end - _IO_buf_base "缓冲区"的长度
上面的定义貌似给出了3个缓冲区,实际上上面的_IO_read_base,
_IO_write_base, _IO_buf_base都指向了同一个缓冲区.
这个缓冲区跟上面程序中的char buf[5];没有不论什么关系.
他们在第一次buffered I/O操作时由库函数自己主动申请空间,最后由对应库函数负责释放.
(再次声明,这里仅仅是glibc的实现,别的实现可能会不同,后面就不再强调了)
请看以下的程序(这里给的是stdin,行缓冲的样例):
#include <stdlib.h> |
能够看到,在读操作之前,myfile的缓冲区是没有被分配的,在一次读之后,myfile的缓冲区才被分配.
这个缓冲区既不是内核中的缓冲区,也不是用户分配的缓冲区,而是实用户进程空间中的由buffered
I/O系统负责维护的缓冲区.
(当然,用户能够能够维护该缓冲区,这里不做讨论了)
上面的样例仅仅是说明了buffered I/O缓冲区的存在,以下从全缓冲,行缓冲和无缓冲3个方面看一下buffered
I/O
是怎样工作的.
1.1. 全缓冲
以下是APUE上的原话:
全缓冲"在填满标准I/O缓冲区后才进行实际的I/O操作.对于驻留在磁盘上的文件一般是由标准I/O库实施全缓冲的"
书中这里"实际的I/O操作"实际上easy引起误导,这里并非读写磁盘,而应该是进行read或write的系统调用
以下两个样例会说明这个问题
#include <stdlib.h> |
上面提到的bbb.txt文件的内容是由非常多行的"123456789"组成
上例中,fgets(buf, 5, myfile); 只读4个字符,可是,缓冲区已被写满,
可是_IO_read_ptr却向前移动了5位,下次再次调用读操作时,
仅仅要要读的位数不超过myfile->_IO_read_end - myfile->_IO_read_ptr
那么就不须要再次调用系统调用read,仅仅要将数据从myfile的缓冲区复制到
buf就可以(从myfile->_IO_read_ptr開始拷贝)
全缓冲读的时候,
_IO_read_base始终指向缓冲区的開始
_IO_read_end始终指向已从内核读入缓冲区的字符的下一个
(对全缓冲来说,buffered I/O读每次都试图都将缓冲区读满)
_IO_read_ptr始终指向缓冲区中已被用户读走的字符的下一个
(_IO_read_end < (_IO_buf_base-_IO_buf_end)) && (_IO_read_ptr ==_IO_read_end)时则已经到达文件末尾
当中_IO_buf_base-_IO_buf_end是缓冲区的长度
一般大体的工作情景为:
第一次fgets(或其它的)时,标准I/O会调用read将缓冲区充满,下一次fgets不调用read而是直接从该缓冲区中拷贝数据,直到
缓冲区的中剩余的数据不够时,再次调用read.在这个过程中,_IO_read_ptr就是用来记录缓冲区中哪些数据是已读的,
哪些数据是未读的.
#include <stdlib.h> |
上面这个是关于全缓冲写的样例.
全缓冲时,仅仅有当标准I/O自己主动flush(比方当缓冲区已满时)或者手工调用fflush时,
标准I/O才会调用一次write系统调用.
样例中,fwrite(buf+i, 1, 512, myfile);这一句仅仅是将buf+i接下来的512个字节
写入缓冲区,因为缓冲区未满,标准I/O并未调用write.
此时,myfile->_IO_write_ptr = myfile->_IO_write_base;会导致标准I/O觉得
没有数据写入缓冲区,所以永远不会调用write,这样aaa.txt文件得不到写入.
凝视掉myfile->_IO_write_ptr = myfile->_IO_write_base;前后,看看效果
全缓冲写的时候:
_IO_write_base始终指向缓冲区的開始
_IO_write_end全缓冲的时候,始终指向缓冲区的最后一个字符的下一个
(对全缓冲来说,buffered I/O写总是试图在缓冲区写满之后,再系统调用write)
_IO_write_ptr始终指向缓冲区中已被用户写入的字符的下一个
flush的时候,将_IO_write_base和_IO_write_ptr之间的字符通过系统调用write写入内核
1.2. 行缓冲
以下是APUE上的原话:
行缓冲"当输入输出中遇到换行符时,标准I/O库运行I/O操作."
书中这里"运行O操作"也easy引起误导,这里不是读写磁盘,而应该是进行read或write的系统调用
以下两个样例会说明这个问题
第一个样例能够用来说明以下这篇帖子的问题
http://bbs.chinaunix.net/viewthread.php?tid=954547
#include <stdlib.h>
//而非只上面须要的个字符 |
上例中, fgets(buf, 5,stdin); 只须要4个字符,可是,输入行中的其它数据也被写入缓冲区,
可是_IO_read_ptr向前移动了5位,下次再次调用fgets操作时,就不须要再次调用系统调用read,
仅仅要将数据从stdin的缓冲区复制到buf2就可以(从stdin->_IO_read_ptr開始拷贝)
stdin->_IO_read_ptr = stdin->_IO_read_end;会导致标准I/O会觉得缓冲区已空,
再次fgets则须要再次调用read.比較一下将该句凝视掉前后的效果
行缓冲读的时候,
_IO_read_base始终指向缓冲区的開始
_IO_read_end始终指向已从内核读入缓冲区的字符的下一个
_IO_read_ptr始终指向缓冲区中已被用户读走的字符的下一个
(_IO_read_end < (_IO_buf_base-_IO_buf_end)) && (_IO_read_ptr ==_IO_read_end)时则已经到达文件末尾
当中_IO_buf_base-_IO_buf_end是缓冲区的长度
#include <stdlib.h> |
这个样例将将FILE结构中指针的变化写入的文件ccc.txt
执行后能够有兴趣的话,能够看看.
上面这个是关于行缓冲写的样例.
stdout->_IO_write_ptr = stdout->_IO_write_base;会使得标准I/O觉得
缓冲区是空的,从而没有不论什么输出.
能够将上面程序中的凝视分别去掉,看看执行结果
行缓冲时,以下3个条件之中的一个会导致缓冲区马上被flush
1. 缓冲区已满
2. 遇到一个换行符;比方将上面样例中buf[4]改为'
'时
3. 再次要求从内核中得到数据时;比方上面的程序加上getchar()会导致立即输出
行缓冲写的时候:
_IO_write_base始终指向缓冲区的開始
_IO_write_end始终指向缓冲区的開始
_IO_write_ptr始终指向缓冲区中已被用户写入的字符的下一个
flush的时候,将_IO_write_base和_IO_write_ptr之间的字符通过系统调用write写入内核
1.3. 无缓冲
无缓冲时,标准I/O不正确字符进行缓冲存储.典型代表是stderr
这里的无缓冲,并非指缓冲区大小为0,事实上,还是有缓冲的,大小为1
#include <stdlib.h> |
对无缓冲的流的每次读写操作都会引起系统调用
1.4 feof的问题
CU上已经有无数的帖子在探讨feof了,这里从缓冲区的角度去考察一下.
对于一个空文件,为什么要先读一下,才干用feof推断出该文件到了结尾了呢?
#include <stdlib.h> |
执行上面的程序,输入多于4个,少于13个字符,而且以连按两次ctrl+d为结束(不要按回车)
从上面的样例,能够看出,每当满足
(_IO_read_end < (_IO_buf_base-_IO_buf_end)) && (_IO_read_ptr ==_IO_read_end)
时,标准I/O则觉得已经到达文件末尾,feof(stdin)才会被设置
当中_IO_buf_base-_IO_buf_end是缓冲区的长度
也就是说,标准I/O是通过它的缓冲区来推断流是否要结束了的.
这就解释了为什么即使是一个空文件,标准I/O也须要读一次,才干使用feof推断释放为空
1.5. 其它说明
非常多新手有一个误解,就是fgets,
fputs代表行缓冲,fread,fwrite代表全缓冲 fgetc,
fputc代表无缓冲
等等.
事实上不是这种,是什么样的缓冲跟使用那个函数没有关系,
而跟你读写什么类型的文件有关系.
上面的样例中多次在全缓冲中使用fgets, fputs,而在行缓冲中使用fread,
fwrite
以下的是引至APUE的
实际上
ISO C要求:
1.当且仅当标准输入和标准输出并不涉及交互式设备时,他们才是全缓冲的
2.标准输出决不是全缓冲的.
非常多系统默认使用下列类型的标准:
1.标准输出是不带缓冲的.
2.如若是涉及终端设备的其它流,则他们是行缓冲的;否则是全缓冲的.