nginx源代码分析--进程间通信机制 & 同步机制

Nginx源代码分析—进程间通信机制

从nginx的进程模型能够知道。master进程和worker进程须要通信，nginx中通信的方式有套接字、共享内存、信号。对于master进程，从外部接受信号，master进程主要就是监控、接受外部信号，将有必要的信号传递给worker进程，master进程大部分时间都是堵塞在sigsuspend()函数调用上。Worker进程屏蔽了全部的外部信号，那么Master进程就通过套接字和worker进程通信，worker进程改动全局变量，使得worker进程接受到了master进程的命令（进程间的套接字被epoll监控）。

共享内存是存放父子进程中都须要的全局变量，比方当前系统接受到的连接，正在处理的连接数目等。

既然使用了共享内存，那么就须要考虑同步，nginx中的同步使用了原子操作、文件锁、信号量（这里信号量的值为1，也就是相当于一个相互排斥锁）。虽说实现了这三种。可是对外都是使用了ngx_shmtx_t变量，这个变量成为一个相互排斥锁。使用上述三种同步方式实现了一种对外的相互排斥锁，接下来看看实现方式：

首先声明一点，在nginx中都是非堵塞的，所以在获取锁的时候也希望是非堵塞的

对于共享内存，使用shmgt &mmap（能够实现文件到内存的映射。也能够不使用文件的方式来实现映射）来实现，共享内存中存放的变量有已经建立成功的TCP连接数、已经处理过的TCP连接数等共6类。共享内存的初始化在Main中实现。共享内存中数据的初始化在ngx_event_module_init函数中实现

上述几种锁的属性设计到堵塞&非堵塞 导致睡眠&不导致睡眠,至于堵塞和非堵塞就是看是否能立即得到调用的结果，依据前提条件选择不同的锁，比方这里用原子操作实现的自旋锁就是堵塞锁。就是假设没有获取锁，那么就连续不断的尝试一段时间，假设是想占有一个被短时间占用的资源的话。能够使用这样的堵塞锁，，假设占用的时间过长，不适合使用堵塞锁，会占用过多的CPU资源。睡眠锁就是在获取锁不成功会导致进程睡眠。缺点是一旦睡眠须要还有一个进程来唤醒，逻辑复杂同一时候CPU的切换消耗时间。

用户能够从锁的使用时间长短角度来选择使用哪一种锁，当锁的使用时间非常短，可使用自旋锁。假设锁使用时间长，使用睡眠锁。堵塞锁就是在一段时间上不停的获取锁直到锁获取成功。

信号量和文件锁都是睡眠锁，信号量使用的sem_wait，文件锁使用fcntl()，只是在死啊用的时候要么成功。要么睡眠。

信号量sem_init能够用于线程间也能够用于进程间。实现相互排斥锁的方法：信号量为0。嗲用sem_post加1。不会有堵塞，调用sem_wait将信号量间1，假设信号量不大于0。就堵塞当前进程（进程进入睡眠），直到其它进程将信号量的值为正数后，这时才干继续通过信号量减1而使得当前进程继续进行。Sem_post解锁，sem_wait实现加锁。

对于稳健锁。ngx_trylock_fd实现不会堵塞，不会使得进程睡眠的相互排斥锁，ngx_lock_fd提供的相互排斥锁在锁已经被的进程拿到时将会导致当前进程进入睡眠状态。

基于原子操作，信号量文件锁。Ngxin封装了一个相互排斥锁。

原子变量锁优先级高于文件锁。

假设不支持原子操作。会使用文件锁实现ngx_shmtx_t相互排斥锁，使用文件锁来提供堵塞、非堵塞的相互排斥锁。

支持原子操作却不支持信号量

支持原子操作的同一时候。操作系统也支持信号量

后两种的差别在于，支持信号量仅仅会影响进程ngx_shmtx_lock方法持有锁的方式，不支持信号量时，和自旋锁一样，支持信号量。自旋锁在堵塞一段时间后没有获取锁，那么信号量导致进程进入睡眠状态，仅仅有等到别的进程释放这个锁才会被激活

在不使用信号量时，nginx相互排斥锁和自旋锁相似，而在使用信号量后将会使用可能让进程进入睡眠，不建议使用带信号量的ngx_shmtx_lock取锁方法。

事实上做了这么多的封装也是为了系统可移植