多进程共享内存续篇-大锁

读写锁，就是多人可以同时访问，但是同时只有一个人可以修改的规则。

由于锁本身的申请和释放，对于性能有很大的消耗，那么一般写只发生在特殊情况，也就是很少发生。

读锁常在就是性能的优化方案，只有在申请写锁的时候，才会释放读锁。

和之前有什么不一样呢，例如，连续的在不同地方的100次读，以前是要100次读锁的申请和释放，现在只有初始的一次申请读锁，中间完全没有别的消耗。

代码如何实现呢？

过程如下：

当有一个进程需要写，那么就要等所有的进程的读锁释放，所以在申请和释放读锁的地方，申请的动作还在。

首先，需要一个共享变量，当一个进程申请写锁，所有进程可以知晓。

然后，以前申请和释放读锁的地方，实际不是申请和释放，而是对于写进程的共享变量的判断。

所谓的判断，如果有进程申请写进程，那么所有进程都会根据共享变量，手动释放一次读锁，然后申请一次读锁。

由于写申请在前，那么在手动释放读锁后，写锁获得权限，申请读锁就要等写锁的释放。

总结：一个进程内的变量read_flag=0，进程开始时候申请读锁，只会申请一次，变量置1。后面再申请和释放，对多进程的共享变量write_flag判断

write_flag=0：无进程申请写锁

申请读锁函数，read_flag==1，进来直接退出；read_flag==0，初次申请；

释放读锁函数，直接return，不用对变量进行判断。

write_flag=1：有进程申请写锁

申请读锁函数，手动申请一次读锁，然后手动释放一次读锁；

释放读锁函数，手动申请一次读锁，然后手动释放一次读锁。

写锁很简单，只需要将共享变量置位，然后去申请写锁就OK了。

注意这里对共享变量的操作，是在没有获得写锁的时候，修改共享变量，如何保证唯一性？

其实不需要唯一性：

其他进程同时申请写锁，那么修改变量都是一个目的，把它置1；

修改的同时，有读锁操作，可能会当时没有读到或读错？那么下次再读呗，只是多了一次读的时间；