条件变量 I – pthread

条件变量是线程同步的另一种方式,实际上,条件变量是信号量的底层实现,这也就意味着,使用条件变量可以拥有更大的自由度,同时也就需要更加小心的进行同步操作。条件变量使用的条件本身是需要使用互斥量进行保护的,线程在改变条件状态之前必须首先锁住互斥量,其他线程在获得互斥量之前不会察觉到这种改变,因为互斥量必须在锁定之后才能计算条件。

模型

pthread_cond_init()

Continue reading

每线程变量

每线程变量有多种实现方式,最原始的方式即是使用数组等数据结构建立线程ID和要访问变量之间的关系, 本文讨论如何借助其他工具来实现变量的每线程存储。

__thread

__thread是gcc扩展关键字,可以实现被声明变量的每线程存储。

输出的结果:

Continue reading

Linux 多进程编程 I

进程的状态

Linux进程有7种基础状态(两种running算一种),除了traced都可以用$ps命令查看,$ps可以查看的进程状态如下:
R running or runnable (on run queue)
D uninterruptible sleep (usually IO)
S interruptible sleep (waiting for an event to complete)
T stopped, either by a job control signal or because it is being traced.
W paging (not valid since the 2.6.xx kernel)
X dead (should never be seen)
Z defunct (“zombie”) process, terminated but not reaped by its parent.

说到进程的状态, 开发过程中最关心的就是两个特殊的状态: 僵尸进程孤儿进程

Orphan Process:一个parent退出,而它的一个或多个child还在运行,那么这些child将成为orphan。将被init(PID==1)收养,并由init对它们完成状态收集工作。init会循环地wait()直到这些child完成了他们的工作. 即当一个孤儿进程凄凉地结束了其生命周期的时候,init进程就会代表党和政府出面处理它的一切善后工作。因此孤儿进程并不会有什么危害。

Zombie Process: 一个使用fork()创建的child,如果child退出,而parent并没有调用wait/waitpid获取child的状态信息,那么child的process descriptor、PID和PCB等资源仍然保存在系统中。此时的child就变成了zombie。因为系统的PID总数是有限的, parent不断的创建child而不去wait,系统早晚会被拖垮.

简而言之:
Orphan/Zombie都是因为在parent中没有wait掉child, 不同之处是orphan的parent已经没了, 由init来接管了,而zombie有个缺德的parent, 不wait还不撒手,拖累了系统. $ps 一下Zombie的进程状态是’Z’

代码模型



		


Linux 常见文件IO接口 II

access()

检查是否调用进程有Access这个文件的权限,如果文件是一个符号链接,会将它解引用,成功返回0,失败返回-1设errno.

mode(Bitwise Or) :
F_OK :文件是否存在
R_OK :文件是否存在且授予了该进程读权限
W_OK:文件是否存在且授予了该进程写权限
X_OK :文件是否存在且授予了该进程执行权限



		




		


fstat()、stat()、lstat()

读取文件状态,fstat()从fd读取,stat () i从pathname读取,lstat()从pathname读取,如果文件是符号链接,则返回符号链接本身的信息,而其他的函数会对链接解引用,ls的底层实现就使用了lstat(),ls出的条目如果是符号链接会直接输出符号链接文件本身的信息



		


一些POSIX宏可以用来检查文件类型,这些宏参数都是stat类型的st_mode成员



		


IPC对象也可以当做文件进而确定其类型,但他们的测试宏的参数是指向stat的指针,而不是st_mode成员



		


这里可以总结下三种获取文件大小的接口:

  1. fseek()把offset移到SEEK_END, 再用ftell()返回文件的大小
  2. lseek() , 返回文件的大小
  3. stat(), struct stat st; st.st_size的数值就是文件大小


		


chmod()、fchmod()

更改文件的权限,这两个函数的唯一区别就是指定文件的方式不一样,成功返回0,失败返回-1,设errno



		


truncate()、ftruncate()

截断文件为指定大小,成功返回0,失败返回-1设errno. 如果原大小 > 指定大小,多余的文件数据被丢弃 如果原大小e < 指定大小,文件被扩展,扩展的部分被填充为’\0′



		


Linux 常见文件IO接口 I

file_descriptor

a small, nonnegative integer for use in subsequent system calls (read(2), write(2), lseek(2), fcntl(2), etc.) ($man 2 open).

  • 一个程序开始运行时一般会有3个已经打开的文件描述符: 0:STDIN_FIFLENO, 1:STDOUT_FILENO, 2:STDERR_FILENO
  • fd从0开始, 查找最小的未被使用的描述符, 把文件表指针与文件表描述符建立对应关系(VS pid是一直向上涨,满了再回来找)
  • 文件描述符就是一个int, 用于代表一个打开的文件, 但是文件的管理信息不能够不是存放在文件描述符中,当使用open()函数打开一个文件时, OS会将文件的相关信息加载到文件表等数据结构中, 但出于安全和效率等因素的考虑, 文件表等数据结构并不适合直接操作, 而是给该结构指定一个编号, 使用编号来进行操作, 该编号就是文件描述符
  • OS会为每个进程内部维护一张文件描述符总表, 当有新的文件描述符需求时, 会去总表中查找最小的未被使用的描述符返回, 文件描述符虽然是int类型, 但其实是非负整数, 也就是0~OPEN_MAX(当前系统中为1024), 其中0,1,2已被系统占用,分别表示stdin, stdout,stderror
  • 使用close()关闭fd时, 就是将fd和文件表结构之间的对应关系从总表中移除, 但不一定会删除文件表结构, 只有当文件表没有与其他任何fd对应时(也就是一个文件表可以同时对应多个fd)才会删除文件表, close()也不会改变文件描述符本身的整数值, 只会让该文件描述符无法代表一个文件而已
  • duplicate fdVS copy fd:dup是把old_fd对应的文件表指针复制给new_fd, 而不是int new_fd=old_fd
  • UNIX使用三种数据结构描述打开的文件:每个进程中用于描述当前进程打开文件的文件描述符表,表示当前文件状态的文件状态标识表,和用于找到文件i节点(索引节点)的V节点表,Linux中并不使用这种Vnode结构,取而代之的是一种通用的inode结构,但本质没有区别,inode是在读取文件时通过文件系统从磁盘中导入的文件位置

file_descriptor_flag

当下的系统只有一个文件描述符标志close-on-exec,仅仅是一个标志,当进程fork一个子进程的时候,在子进程中调用了exec函数时就用到了该标志。意义是执行exec前是否要关闭这个文件描述符。

  • 一般我们会调用exec执行另一个程序,此时会用全新的程序替换子进程的正文,数据,堆和栈等。此时保存文件描述符的变量当然也不存在了,我们就无法关闭无用的文件描述符了。所以通常我们会fork子进程后在子进程中直接执行close关掉无用的文件描述符,然后再执行exec。但是在复杂系统中,有时我们fork子进程时已经不知道打开了多少个文件描述符(包括socket句柄等),这此时进行逐一清理确实有很大难度。我们期望的是能在fork子进程前打开某个文件句柄时就指定好:这个句柄我在fork子进程后执行exec时就关闭”。所以就有了 close-on-exec
  • 每个文件描述符都有一个close-on-exec标志。在系统默认情况下,这个标志最后一位被设置为0。即关闭了此标志。那么当子进程调用exec函数,子进程将不会关闭该文件描述符。此时,父子进程将共享该文件,它们具有同一个文件表项,也就有了同一个文件偏移量等。
  • fcntl()FD_CLOEXECopen()O_CLOEXEC用来设置文件的close-on-exec,当将close-on-exec标志置为1时,即开启此标志, 此时子进程调用exec函数之前,系统就已经让子进程将此文件描述符关闭。

Note:虽然新版本支持在open时设置CLOEXEC,但是在编译的时候还是会提示错误 – error: ‘O_CLOEXEC’ undeclared (first use in this function)。这个功能需要设置宏(_GNU_SOURCE)打开。



		


file_status_flag



		


open()



		




		


FQ:Why Bitwise ORed:
FA:猜想有以下模型:用一串某一位是1其余全是0的字符串表示一个选项, 选项们作 “按位与”就可得到0/1字符串, 表示整个flags的状态, Note: 低三位表示Access Mode

create()

等价于以O_WRONLY |O_TRUNC|O_CREAT的flag调用open()



		


dup()、dup2()、dup3()



		




		




		


read()



		




		


write()



		




		


Note: 上例中即使只有一个字符’A’,也要写”A”,因为”A”才是地址,’A’只是个int

lseek()

l 表示long int, 历史原因



		




		


fcntl()



		


建议锁(Adversory Lock)

限制加锁,但不限制读写, 所以只对加锁成功才读写的程序有效,用来解决不同的进程 同时同一个文件同一个位置 “写”导致的冲突问题
读锁是一把共享锁(S锁):共享锁+共享锁+共享锁+共享锁+共享锁+共享锁
写锁是一把排他锁(X锁):永远孤苦伶仃

释放锁的方法(逐级提高):

  • 将锁的类型改为:F_UNLCK, 再使用fcntl()函数重新设置
  • close()关闭fd时, 调用进程在该fd上加的所有锁都会自动释放
  • 进程结束时会自动释放所有该进程加过的文件锁

Q:为什么加了写锁还能gedit或vim写???

A:可以写, 锁只可以控制能否加锁成功, 不能控制对文件的读写, 所以叫”建议”锁, 我加了锁就是不想让你写, 你非要写我也没办法. vim/gedit不通过能否加锁成功来决定是否读写, 所以可以直接上

Q: So如何实现文件锁控制文件的读写操作????

A:可以在读操作前尝试加读锁, 写操作前尝试加写锁, 根据能否加锁成功决定能否进行读写操作



		


ioctl()

这个函数可以实现其他文件操作函数所没有的功能,大多数情况下都用在设备驱动程序里,每个设备驱动程序可以定义自己专用的一组ioctl命令,系统则为不同种类的设备提供通用的ioctl命令



		


close()