OS on NoneBack

Epoll and IO复用

Sun, 15 Aug 2021 21:47:45 +0800

先从epoll说起。

epoll是Linux内核的可拓展IO事件通知机制，设计的目的是取代select和poll，是为了处理大量文件描述符而改进的poll，支持打开文件描述符上限是系统最大文件打开数目，性能优异。

使用

API

epoll相关的系统调用有三个

cpp


/** epoll_create
 * 创建一个epoll句柄，返回错误码
 * 使用之后需要被关闭，因为epfd也会消耗系统fd数量。
 * size : 标识epfd监听fd的数量
 */
int epoll_create(int size);

/** epoll_ctl
 * 添加epoll监控对象，epoll事件的注册函数，返回错误码
 * epfd : epoll fd
 * op : 操作类型
 * EPOLL_CTL_ADD : 注册新的fd到epfd中
 * EPOLL_CTL_MOD : 修改已经注册的fd的监听事件
 * EPOLL_CTL_DEL : 从epfd中删除一个fd
 * fd : 需要监听的fd
 * event : 需要监听的事件
 * EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
 * EPOLLOUT：表示对应的文件描述符可以写；
 * EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
 * EPOLLERR：表示对应的文件描述符发生错误；
 * EPOLLHUP：表示对应的文件描述符被挂断；
 * EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
 * EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里
 */
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

/** epoll_wait
 * 收集已经触发了的事件，返回触发事件的数目，0代表超时
 * epfd : epoll fd
 * events : epoll将触发的事件赋值到events数组中
 * maxevent : 告知kernel events数组的大小，不得大于epoll_create 中的 size
 * timeout : 等待超时时间，0，立即返回，-1 一直阻塞，> 0 等待对应时间
 */
int epoll_wait(int epfd, struct epill_event* events,int timeout);

处理过程

epoll_create

当一个进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体

cpp


struct eventpoll {
 /* Protect the this structure access */
 spinlock_t lock;

 /*
 * This mutex is used to ensure that files are not removed
 * while epoll is using them. This is held during the event
 * collection loop, the file cleanup path, the epoll file exit
 * code and the ctl operations.
 */
 struct mutex mtx;

 /* Wait queue used by sys_epoll_wait() */
 /* 阻塞在epoll_wait()当前epoll实例的用户被链接到这个等待队列 */
 wait_queue_head_t wq;

 /* Wait queue used by file->poll() */
 /* epoll文件也可以被epoll_wait() */
 wait_queue_head_t poll_wait;

 /* List of ready file descriptors */
 /* 已经ready的epitem的链表 */
 struct list_head rdllist;

 /* RB tree root used to store monitored fd structs */
 struct rb_root rbr;

 /*
 * This is a single linked list that chains all the "struct epitem" that
 * happened while transfering ready events to userspace w/out
 * holding ->lock.
 */
 /* 见ep_poll_callback()以及ep_scan_ready_list()中的注释 */
 struct epitem *ovflist;

 /* The user that created the eventpoll descriptor */
 /* 创建当前epoll实例的用户 */
 struct user_struct *user;

 struct file *file;

 /* used to optimize loop detection check */
 int visited;

 struct list_head visited_list_link;//双向链表中保存着将要通过epoll_wait返回给用户的、满足条件的事件
};

在epoll_create中，epoll向内核注册了一个红黑树，用于存储上述的被监控socket。当你调用epoll_create时，就会在这个rb tree里创建一个file结点，通过rb tree查询对应的socket fd。

同时，它还会创建一个双向链表用于存储准备就绪的事件。

epoll_ctl

在epoll中，对于每一个事件都会建立一个epitem结构体：

cpp


/*
 * Each file descriptor added to the eventpoll interface will
 * have an entry of this type linked to the "rbr" RB tree.
 */
struct epitem {
 /* RB tree node used to link this structure to the eventpoll RB tree */
 /* eventpoll内部的红黑树的挂载点 */
 struct rb_node rbn;

 /* List header used to link this structure to the eventpoll ready list */
 /* 所有已经ready的epitem都会被挂载到eventpoll的rdllist中 */
 struct list_head rdllink;

 /*
 * Works together "struct eventpoll"->ovflist in keeping the
 * single linked chain of items.
 */
 /* 配合eventpoll->ovflist使用 */
 struct epitem *next;

 /* The file descriptor information this item refers to */
 /*
 * 作为evetnpoll内部的红黑树节点的key
 */
 struct epoll_filefd ffd;

 /* Number of active wait queue attached to poll operations */
 /* 监听队列挂载数 */
 /* 难道一个epitem还能同时挂载到多个监听队列？ */
 int nwait;

 /* List containing poll wait queues */
 /* 链接当前epitem对应的eppoll_entry结构 */
 struct list_head pwqlist;

 /* The "container" of this item */
 /* 关联当前epitem所属的epollevent */
 struct eventpoll *ep;

 /* List header used to link this item to the "struct file" items list */
 /* 与所监听的struct file进行链接 */
 struct list_head fllink;

 /* The structure that describe the interested events and the source fd */
 /* 通过epoll_ctl从用户空间传过来的数据，表示当前epitem关心的events */
 struct epoll_event event;
};

在调用epoll_ctl时，除了将socket fd注册到eventpoll的rb tree，它还会给内核中断处理程序注册一个回调函数。当这个fd的中断到了，就把它放入就绪链表中。当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。

epoll_wait

当epoll_wait调用时，仅仅观察这个list链表里有没有数据即eptime项即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。

Epoll使用模型

cpp


for( ; ; )
 {
 nfds = epoll_wait(epfd,events,20,500);
 for(i=0;i<nfds;++i)
 {
 if(events[i].data.fd==listenfd) //有新的连接
 {
 connfd = accept(listenfd,(sockaddr *)&clientaddr, &clilen); //accept这个连接
 ev.data.fd=connfd;
 ev.events=EPOLLIN|EPOLLET;
 epoll_ctl(epfd,EPOLL_CTL_ADD,connfd,&ev); //将新的fd添加到epoll的监听队列中
 }

 else if( events[i].events&EPOLLIN ) //接收到数据，读socket
 {
 n = read(sockfd, line, MAXLINE)) < 0 //读
 ev.data.ptr = md; //md为自定义类型，添加数据
 ev.events=EPOLLOUT|EPOLLET;
 epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);//修改标识符，等待下一个循环时发送数据，异步处理的精髓
 }
 else if(events[i].events&EPOLLOUT) //有数据待发送，写socket
 {
 struct myepoll_data* md = (myepoll_data*)events[i].data.ptr; //取数据
 sockfd = md->fd;
 send( sockfd, md->ptr, strlen((char*)md->ptr), 0 ); //发送数据
 ev.data.fd=sockfd;
 ev.events=EPOLLIN|EPOLLET;
 epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev); //修改标识符，等待下一个循环时接收数据
 }
 else
 {
 //其他的处理
 }
 }
 }

阻塞IO、非阻塞IO、IO复用

阻塞IO意味着线程在数据未到达时需要等待数据到达，阻塞的进程是不应当占用CPU的，此时需要让出CPU，调入新的task占用CPU。知道数据到达，再重新获取将这个task调入CPU执行。用户进程独立处理业务

cpp


 printf("Calling recv(). \n");
 ret = recv(socket, recv_buf, sizeof(recv_buf), 0);
 printf("Had called recv(). \n");

基于此，当大量task出现读写请求时，大量的CPU上下文切换，task调度，效率可能会低下

非阻塞IO

当用户线程发起一个IO操作后，并不需要等待，而是马上就得到了一个结果。如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送IO操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。

在非阻塞IO模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。

cpp


while(1)
{
 printf("Calling recv(). \n");
 ret = recv(socket, recv_buf, sizeof(recv_buf), 0);
 if (EAGAIN == ret) {continue;}
 else if(ret > -1) { break;}
 printf("Had called recv(), retry.\n");
}

对于非阻塞IO就有一个非常严重的问题，在while循环中需要不断地去询问内核数据是否就绪，这样会导致CPU占用率非常高，因此一般情况下很少使用while循环这种方式来读取数据。

IO复用

阻塞IO的问题是，业务交由线程处理，阻塞导致大量的资源被占用；阻塞与恢复会可能会导致大量的上下文切换,效率低下；

非阻塞IO的问题是，在不使用监视器的情况下，依靠死循环完成一次 IO 操作。但是这样做的效率实在是太低了，完全没有实际意义；

实际上，task的运行是不可避免的，有数据需要处理，就需要CPU去执行。所以可以优化的点在于，如何减少运行处理业务的线程以减少上下文调度开销和等待线程资源占用，以及减少CPU无意义的空转。

IO复用的基本思想就是，在一个线程中管理监听多个fd事件，减少上下文切换；采用事件通知机制，减少CPU的空转；

由此衍生出的select，poll，epoll，不过此乃他话，姑且不论。

参考

Linux下的I/O复用与epoll详解

深入理解 epoll

Linux中的Fork

Thu, 18 Feb 2021 15:56:31 +0800

这原本是大二时学习操作系统是写下的一篇博客，近几日对它稍微添加了一些COW的内容。

前言

最近最学习操作系统，在《operating system concept》的进程一章节中中有这样一段代码:

c


#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
int main(){
 pid_t pid;
 pid=fork();
 if(pid<0){
 //create process failed
 printf("Failed\n");
 exit(-1);
 }else if(pid==0){
 //child process;
 printf ("Child pid %d\n",getpid());
 execlp("/bin/ls","ls",NULL);
 }else{
 //parent process;
 printf("Parent pid %d\n",getpid());
 wait(NULL);
 printf ("Child complete\n");
 return 0;
 }
}

查阅了些资料，看了几回才稍微看懂一点fork()的用法，于是写下这篇博客记录一下。

fork()函数介绍

简介：建立一个新的进程

表头文件：

c

#include <uistd.h>

定义函数：

c

pid_t vfork(void);

函数说明：

vfork()会产生一个新的子进程，其子进程会复制父进程的数据与堆栈空间，并继承父进程的用户代码，组代码，环境变量、已打开的文件代码、工作目录和资源限制等。Linux 使用copy-on-write(COW)技术，只有当其中一进程试图修改欲复制的空间时才会做真正的复制动作，由于这些继承的信息是复制而来，并非指相同的内存空间，因此子进程对这些变量的修改和父进程并不会同步。此外，子进程不会继承父进程的文件锁定和未处理的信号。注意，Linux不保证子进程会比父进程先执行或晚执行，因此编写程序时要留意死锁或竞争条件的发生。

返回值：

如果vfork()成功则在父进程会返回新建立的子进程代码(PID)，而在新建立的子进程中则返回0。如果vfork 失败则直接返回-1，失败原因存于errno中。

错误代码：

EAGAIN 内存不足。ENOMEM 内存不足，无法配置核心所需的数据结构空间。

函数使用分析

首先我们看看开头代码的运行结果：

Linux中进程是通过链表进行组织的，所以本文中使用 ParentProcess->ChildrenProcess的格式展示。

下面开始上面分析结果：

首先，fork()函数会调用两次，第一次在父进程中返回，返回子进程的pid(一般大于零），第二次是在子进程中调用，返回0;当fork()失败时，返回一个负数。
父进程开使执行，调用fork()，返回一个子进程pid(>0)，执行打印Parent pid 25974,然后等待子进程。
子进程在父进程调用fork()后开始执行，在子进程中fork()返回０（并不是实际意义上的调用之后返回，而是在子进程中直接返回了０,在后面在解释），执行父进程fork()后面的语句，即execlp("/bin/ls",“ls”,NULL)，即调用ls，打印当前目录的文件，子进程结束。
父进程接受信号，结束主进程。

理解fork的执行

现在我们来看看这一段代码：

c


/*
 * @Description: In User Settings Edit
 * @Author: NoneBack
 * @Date: 2019-09-30 01:00:29
 * @LastEditTime: 2019-09-30 22:52:24
 * @LastEditors: NoneBack
 */
#include <stdio.h>
#include <unistd.h>
int main(void) {
 int i = 0;
 printf("i son/pa ppid pid fpid\n");
 // ppid指当前进程的父进程pid
 // pid指当前进程的pid,
 // fpid指fork返回给当前进程的值
 for (i = 0; i < 2; i++) {
 pid_t fpid = fork();
 if (fpid == 0)
 printf("%d child %4d %4d %4d\n", i, getppid(), getpid(), fpid);
 else
 printf("%d parent %4d %4d %4d\n", i, getppid(), getpid(), fpid);
 wait(NULL); //等待子进程
 }
 return 0;
}

下面是它的执行结果：

下面我们来看看为什么会有这样的结果：

１．首先父进程中，i=0时，打印0 parent 26826 26917 26918，随后父进程等待子进程执行。

子进程接着拷贝父进程（连同ＰＣ），接着父进程中i=0时fork()之后的代码运行，打印0 child 26917 26918 0，此时子进程在i=0时的fork()返回０。

子进程i=1时候的fork()接着生成一个孙子进程，并返回其pid,子进程打印1 parent 26917 26918 26919，生成的孙子进程中从i=1的fork()出接着执行，此处的fork()返回０，打印1 child 26918 26919 0。第一个子进程结束。

２.父进程中i=1时，执行fork()，生成子进程，打　印1 parent 26826 26917 26920。

子进程接着执行1=1时，fork()之后的代码,打印1 child 26917 26920 0。进程结束。

至于为什么父进程是１,这是另一方面的知识，暂且不管。

Fork里的COW机制

一开始便说了，fork执行之后,产生一个新的子进程，其子进程会复制父进程的数据与堆栈空间，并继承父进程的用户代码，组代码，环境变量、已打开的文件代码、工作目录和资源限制等。这里的复制使用了COW（Copy on Write）机制。

什么是Copy On Write

COW本质上是一种Lazy Copy的思想。

写入时复制（英语：Copy-on-write，简称COW）是一种计算机程序设计领域的优化策略。

其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的（transparently）。

此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被建立，因此多个调用者只是读取操作时可以共享同一份资源。

在使用fork创建子进程时，只有当有进程需要修改的时候才会真正的执行数据的拷贝，之后再在进程自己的数据段修改数据。否则，如果进程只有读请求的话，实际上不需要不执行资源的复制，只需要在不同进程之间维护对资源的引用即可。

fork中COW技术实现原理

fork()之后，kernel把父进程中所有的内存页的权限都设为read-only，然后子进程的地址空间指向父进程。当父子进程都只读内存时，相安无事。

当其中某个进程写内存时，CPU硬件检测到内存页是read-only的，于是触发页异常中断（page-fault），陷入kernel的一个中断例程。

中断例程中，kernel就会把触发的异常的页复制一份，于是父子进程各自持有独立的一份，之后进程再修改对应的数据。

总结

fork()会返回两次，第一次在父进程中返回fork()出的子进程的pid,第二此在子进程中返回０，接着从fork()处之后的代码开始执行。

fork()会产生一个新的子进程，其子进程会复制父进程的数据与堆栈空间，并继承父进程的用户代码，组代码，环境变量、已打开的文件代码、工作目录和资源限制等。

复制资源的核心是COW思想。

好处

COW技术可减少分配和复制大量资源时带来的瞬间延时。
COW技术可减少不必要的资源分配。比如fork进程时，并不是所有的页面都需要复制，父进程的代码段和只读数据段都不被允许修改，所以无需复制。

缺点

如果在fork()之后，父子进程都还需要继续进行写操作，那么会产生大量的分页错误(页异常中断page-fault)，这样就得不偿失。

参考

vfork

fork函数详解

进程的同步与互斥

Fri, 01 Nov 2019 00:00:00 +0000

进程的同步与互斥

[TOC]

进程的同步

引入

在多进程的系统中，进程是并发执行的，进程具有“异步”的天性，异步性指的是各并发执行的进程以各自独立的、不可预知的速度向前推进。

我们知道多进程存在对共享资源的访问，如果对异步性不加控制，那么多进程的不可预知的执行次序会导致对共享数据的脏读、误读、幻读等莫名错误，这样的话，我们的进程拿不到准确的数据，多进程的并发优势反而得不偿失。

为了能避免异步性带来的副作用，我们就引入了“进程同步”，这是个辅助手段，主要解决异步性带来的“不可预知性”。

进程同步机制就是针对解决异步进程间的执行次序的“不可预知性”，保证多个进程之间按照某种设计好的、程序能控制的执行次序，以达到对共享资源访问的能控性、有效性、准确性

进程同步的控制机制

基于 P 、 V 操作的信号量机制

最早出现的用来解决进程同步与互斥问题的机制 , 包括一个称为信号量的变量及对它进行的两个原语操作。

==key==

一个信号量的建立必须经过说明 , 即应该准确说明 s 的意义和初值 , 信号量的值仅能由 PV 原语来改变。P 操作是申请资源 , 它使信号量值减 1 , 若结果非负 , 该进程继续 , 否则该进程被封锁 ;V 操作是释放资源 , 它使信号量值增 1 ，若结果大于零 , 该进程继续 , 否则从该信号量的等待队列中移出一个进程 , 解除它的等待状态。

管程机制

概念引入：

为实现进程间的同步在每个并发进程中都要设置大量的同步操作原语 , 这不仅给编程带来麻烦 , 且会因 P 操作使用不当而导致数据的不定性或死锁;

同时操作系统的结构不够清晰。因此后来又提出了一种集中式同步进程 ———**管程 **。

基本思想：将共享变量和对它们的操作集中在一个模块中 , 操作系统或并发程序就由这样的模块构成。这样模块之间联系清晰 , 便于维护和修改 , 易于保证正确性。
从语言的角度看，管程主要有以下特性：（1）模块。管程是一个基本程序单位，可以单独编译;
（2）抽象。管程是中不仅有数据，而且有对数据的操作;
（3）封装。管程外可以调用管程内部定义的一些函数，但函数的具体实现外部不可见;对于管程中定义的共享变量的所有操作都局限在管程中，外部只能通过调用管程的某些函数来间接访问这些变量。
为了保证共享变量的数据一致性，管程应互斥使用。
管程通常是用于管理资源的，因此管程中有进程等待队列和相应的等待和唤醒操作。

在管程入口有一个等待队列，称为入口等待队列。当一个已进入管程的进程等待时，就释放管程的互斥使用权；当已进入管程的一个进程唤醒另一个进程时，两者必须有一个退出或停止使用管程。在管程内部，由于执行唤醒操作，可能存在多个等待进程（等待使用管程），称为紧急等待队列，它的优先级高于入口等待队列。因此，一个进程进入管程之前要先申请，一般由管程提供一个enter过程；离开时释放使用权，如果紧急等待队列不空，则唤醒第一个等待者，一般也由管程提供外部过程leave。
管程内部有自己的等待机制。管程可以说明一种特殊的条件型变量：var c:condition；实际上是一个指针，指向一个等待该条件的PCB队列。
- 对条件型变量可执行wait和signal操作： wait(c):若紧急等待队列不空，唤醒第一个等待者，否则释放管程使用权。执行本操作的进程进入C队列尾部； signal(c):若C队列为空，继续原进程，否则唤醒队列第一个等待者，自己进入紧急等待队列尾部。
总结：管程(monitor)是一种基本的，高级的同步构造，是为了解决信号量因不正确的使用而导致的一些时序错误而提出的一种高级语言构造。管程也是进程同步的一种方式，相比于其他进程同步方式，管程将共享变量和对它们的操作集中在一个模块中，操作系统或并发程序就由这样的模块构成。这样模块之间联系清晰，便于维护和修改，易于保证正确性。管程只是保证了同一时刻只有一个进程在管程内活动,即管程内定义的操作在同一时刻只被一个进程调用(由编译器实现).但是这样并不能保证进程以设计的顺序执行,因此需要设置condition变量,让进入管程而无法继续执行的进程阻塞自己。

会合机制

会合机制的提出

在不具有公共内存的分布式操作系统中，要使用P，V操作或管程机制存在着十分大的问题–信号灯量和管程共享变量存放在何处？

如果分步式系统中有两个主机H1和H2，它们之间并没有公共内存，H1中有进程P1，H2中有进程P2，如果有一个信号量(或管程共享变量)S，那S放在何处呢？

如果放在H1中，显然P2无法访问到S；同理，如果放在H2中,S对P1又是不可访问的。

显然，P，V操作和管程都是以进程所操作的对象为核心的，而这些对象在无公共内存的分布式操作系统中的存储是一个不可克服的困难。

因此，自然希望在分布式操作系统中的同步机制应该避开这些被动的成分，而以主动成分–进程直接进行相互作用。因而，产生了会合这一种同步机制。

会合的一般形式 一个进程可以有许多入口，一个入口对应一段程序，一个进程可以调用另一个进程的入口。当一个进程调用另一个进程的入口，而且被调用的进程已准备好接受这个调用时，会合就发生了。

当调用者发出调用请求时，被调用的进程未准备接受这个调用时，则调用者等待；反之，当被调用者准备接受调用，而当前尚无调用者时，则被调用者等待。即先到达会合处者等待后到达者。

当多个进程调用同一个进程的同一个入口时，被调用者按先来先服务（FCFS）的次序接受调用。入口处可以携带调用参数，还可以有返回参数，以实现信息的交换。被调用者可以选择会合的入口。

Petri 网

利用Petri网进行程序设计的内容较为抽象和晦涩，在此仅大概介绍一下，有兴趣可以自行查找相关资料。

Petri 网是一种适于描述和分析异步并发系统的有力工具。Petri 网是德国的C.A.Petri 于 1962 年在他的博士论文中首先提出的 , 用以构造系统模型及动态特性分析。在计算机科学的许多领域 , 如并行计算、分布式数据库设计等 , Petri网系统已起到了越来越重要的作用。

( 1) Petri 网是以图形表示的模型 , 直观性强

( 2) Petri 网中的托肯（Petri网中的一个成分）流动表现了系统的动态演变过程。

( 3) Petri 网能准确地刻画系统的一些重要特性 , 如 : 并发、冲突、同步、异步、死锁、饥饿、溢出等。

( 4) 有一套严格的数学理论和分析方法 , 支持对系统模型的各种性质的分析和性能评价。

Petri网是一种适合于描述异步并发现象的系统模型，它既有严格的数学定义，又有直观的图形表示，借由它可以很好的表示程序的运行过程以及状态（并发、冲突、同步、异步、死锁、饥饿、溢出等 )。通过对网图的分析、同步合成和共享合成，将串行进程并行化 , 中间过程运用从粗到细的逐步精炼思想 , 最终获得一个高效、正确的并行程序。

demo:

进程的互斥

引入

“进程互斥“与“进程同步“本质上都是在围绕同一个话题在讨论，即如果保证多进程对**共享资源（如，内存数据、打印机、摄像头）**访问的可控性、有效性和正确性；

所以，共享资源才是研究的核心对象

我们在这需要讨论的是，在某个时间段内，因为存在多个进程的“异步”运行、存在对共享资源的“乱序”持有及改动，所以，如果这个“时间段”不让进程的发生切换，即限制这个时间段内，只允许一个进程开展任务，任务完成之前，该进程不释放当前持有的共享资源，其他的进程在这段时间内也不能抢占这个资源；

这种在“时间段”角度下，解决并发访问共享资源问题的机制，就叫做“进程互斥”

进程互斥的四大原则

1.空闲让进。当临界资源处于空闲状态，允许一个请求进入临界区的进程立即进入临界区，从而有效的利用资源。

2.忙则等待。已经有进程进入临界区时，意味着相应的临界资源正在被访问，所以其他准备进入临界区的进程必须等待，来保证多进程互斥。

3.有限等待。对要求访问临界资源的进程，应该保证该进程能在有效的时间内进入临界区，防止死等状态。

4.让权等待。当进程不能进入临界区，应该立即释放处理机，防止进程忙等待。

进程互斥的实现机制

下面介绍历史上对进程互斥的实现方法：

软件实现

单标志法

问题：违背“空闲让进”的原则

单标志法在一些情况下确实能达到互斥访问的效果，但是这个算法也存在很大的缺陷，比如上面的turn初始为0，如果P0进程一直还未曾执行过临界区代码，那么临界资源就不会被P0占用，并处于空闲状态，但是这种情况下，P1进程也只能看着临界资源空闲也没法占有，因为P1在第5部被while循环“卡住”了。

双标志先检查法

问题：双标志先检查法的算法设计中忽视并发进程存在异步性。违反“忙则等待”原则

具体来说，如果上图中的P0进程和P1进程在交替运行后，分别执行完了第1步和第5步，并且还未曾执行第2步和第6步，这种情况在不可预知的异步性下，是完全有可能发生的，但是如果真发生这种执行状况，那么P0和P1就都可以进入临界区了，原本想到达的互斥效果，就失败了；

这个算法错误的根本原因在于：进入区的“检查”（while轮训）和“上锁”（设置flag）两个处理不是一气呵成的；“检查”后，“上锁”前的这个时间间隙有可能会发生进程切换，导致其他进程“有机可乘”；当然，如果“检查”和“上锁”是一个不可分割的原子操作，那么这个算法的问题就可以解决了**；**

双标志后检查法

问题：与双标志先检查法一样，忽略了并发进程的异步性。

因此，双标志后检查法虽然解决了“忙则等待”的问题，但是又违背了“空闲让进”和“有限等待”原则，会因各进程都长期无法访问临界资源而产生“饥饿”现象；

Peterson算法

从Peterson算法的while条件的设计，可以看出，它综合了单标志算法和双标志检查算法的优点，做到了兼顾“公平性”和“互斥性”；

问题：依然没有遵循让权等待的原则。

事实上运用进程同步一些的机制（信号量，管程等）也能实现临界资源的互斥，在此不多说。

硬件实现

中断屏蔽方法

缺点：

不适用于多核CPU，因为关中断指令只对执行该指令的CPU有效，如果是多核CPU，那么这个指令不会影响其他核的中断处理机制；因此，这种方式只能保证执行关中断指令的这个核不进行进程切换，但是其他核的进程还是有可能丝毫不受阻拦的访问该临界资源，所以总体上看，还是没法保证进程对临界资源的互斥访问；

开关中断指令是特权指令，只能在内核态下执行，因此用户态进程无法使用这个功能，否则必须切换至内核态下；

TestAndSet指令

TSL指令是用硬件实现的，执行的过程不允许被中断，只能一气呵成 所谓“硬件实现”，可以理解为TSL看似是一堆指令的集合，但是这一堆指令可以在硬件上只需要一个时钟周期就可完成，所以这一堆指令是不会被中断，不会被破坏的；

TSL指令逻辑的C语言描述，注意这里只是描述，真实的执行过程就是一个瞬间的硬件操作而已；

cpp


//lock 表示当前临界区是否被加锁
bool TestAndSet(bool *lock){
 bool old=*lock;
 *lock=true;
 return old;
}

这段描述的核心就是共享变量lock，对于多个进程竞争临界资源时，这个共享的lock变量，是全局的、独一无二的；

下面来分析一下这段描述：

cpp


// 将TestAndSet 配合 while一起使用
while(TestAndSet(&lock)) ;
//临界区代码
lock=false;
//剩余区代码

while会陷入死循环，直到lock出现过一次false，就跳出循环接着往下执行，并且跳出循环后，lock最终还是被设成true；

因为TestAndSet()函数是硬件实现的，属于原子操作，所以当进程共享的变量lock被其他进程修改成false之后，TestAndSet能保证当前进程对lock**“瞬间”**上锁。

这个“瞬间”过程可以描述为：

获得lock的false空闲锁状态；

将lock设为true，即上锁；

基于false作为返回值来跳出while死循环；

Swap指令

Swap指令和上面的TSL指令一样，也是通过硬件实现的，执行过程不允许被中断，只能一气呵成

cpp


//swap指令的作用是交换两个变量的值。
void Swap(bool *a , bool *b){
 bool temp=*a;
 *a=*b;
 *b=temp;
}

与TSL指令类似，它能保证a、b两个变量在**“瞬间”**一定被交换成功。

cpp


//lock表示当前临界区是否被加锁。
bool old=true;
while(old==true){
 Swap(&lock,&old);
}
//临界区代码
lock=false;
//剩余区代码

while会陷入死循环，直到lock出现一次false，old就被换成false，并跳出循环，跳出循环后，lock自身变成了old的true，即实现了**“瞬间”**上锁；

这个**“瞬间”**过程的慢动作回放如下：

lock出现false，即空闲锁状态；

old被换成false，lock被换成true，即上锁；

while条件不满足，跳出死循环

关于TSL和Swap：