首先我想问的是这两个p代表的是什么?

系统调用pread和pwrite完成与read和write相类似的工作,只是前两者会在offset参数所指定的位置进行文件IO操作,而非始于文件的当前偏移量处,并且它们不会改变文件的当前偏移量。

#include <unistd.h>

ssize_t pread(int fd, void *buf, size_t count, off_t offset);

ssize_t pwrite(int fd, const void *buf, size_t count, off_t offset);

pread调用等同于将如下调用纳入同一原子操作:

off_t orig;

orig = lseek(fd, 0, SEEK_CUR);   /*save current offset*/

lseek(fd, offset, SEEK_SET);

s = read(fd, buf, len);

lseek(fd, orig, SEEK_SET);       /*Restore original file offset*/

对pread和pwrite的而言,fd所指代的文件必须是可定位的(即允许对文件描述符执行lseek动作)。

多线程应用为这些系统调用提供了用武之地。进程下辖的所有线程将共享同一文件描述符表。这也意味着每个已打开文件的文件偏移量为所有线程所共享。当调用pread或者pwrite的时候,多个线程可以同时对同一文件描述符执行IO操作,且不会因其他线程修改文件偏移量而受到影响。如果还试图使用lseek和read或者write来代替pread或者pwrite将引发竞争状态,这类似于讨论O_APPEND文件标志一样(多个进程的文件描述符指向同时打开的文件句柄时,使用pread和pwrite同样可以避免出现竞争状态)。

如果需要反复执行lseek,并伴之以文件IO,那么pread和pwrite可以在某些情况下提供一些性能优势。这是因为执行单个的pread或pwrite系统调用的成本要低于lseek和read或者write两个的系统调用。然而较之于执行IO实际所需的时间,系统调用的开销就有些相形见绌了。

实际执行IO的时间要远大于系统调用的时间,系统调用的性能优势作用有限。

最新文章

  1. OpenLayers Map理解
  2. .NET中Debug模式与Release模式
  3. ubuntu 修该rm命令使删除文件到回收站
  4. 嵌入式 Linux 应用:概述
  5. 【原】Spark中Client源码分析(一)
  6. 在Vivado中调用ModelSim生成FSM的状态转移图
  7. 使用PHP预定义变量得到url地址及相关参数
  8. 我的HttpClients工具
  9. C/C++堆栈指引(转)
  10. 格而知之6:我所理解的Runtime(1)
  11. 【解决方案】Django管理页面无法显示静态文件
  12. SQL Server 基本操作之三种增加法
  13. selenium 设置代理的话,可以使用这种方式,代码是我刚才测试过的,亲测可用
  14. sonyflake.go
  15. C#调用Windows(8/10)自带的虚拟键盘
  16. VMWare安装
  17. Maven中可以被继承的POM元素
  18. js apply使用
  19. php中memcached的使用
  20. 实例详解:MFC坐标轴实现

热门文章

  1. 【饿了么】—— Vue2.0高仿饿了么核心模块&amp;移动端Web App项目爬坑(三)
  2. beyond compare 比较Xls文件时只显示有差异的列
  3. Unity5.1 新的网络引擎UNET(十五) Networking 引用--下
  4. STL - C++ 11的Lambda表达式(上)
  5. FLV视频播放:对未缓冲进度条实现拖动
  6. QtGui.QSlider
  7. WCF学习笔记之序列化
  8. ant design pro (八)构建和发布
  9. Java之JVM调优案例分析与实战(2) - 集群间同步导致的内存溢出
  10. linux 下处理大文件