说出你所知道的各类linux系统的各类同步机制（重点），什么是死锁？如何避免死锁
linux系统的通讯机制，主要是指进程间通讯，其实通讯就是进程同步的手段。如果问进程间同步，见问题7，这里要说的linux系统的同步机制是讲线程间的同步。
简单总结一下。更多资料参考《unix环境高级编程》、《操作系统》。
互斥量
首先是最基础的加锁原语，互斥量。既确保同一时间只有一个线程访问数据，通过在访问共享资源前对互斥量加锁，阻塞其他试图再次加锁的线程知道互斥锁被释放。互斥的具体实现有多种方法，例如开关中断，使用原子的机器指令。
读写锁
与互斥量类似，不过允许更高的并行性。读写锁有三种状态，读模式的加锁，写模式的加锁，不加锁状态。一次只有一个线程可以占有写模式的读写锁，但是可以多个线程可以同时占用读模式的读写锁。既读模式下可以共享，写模式下互斥。一般一个线程试图以读模式获取锁时，读写锁通常会阻塞随后的读模式锁请求。
条件变量
互斥量是加锁原语，条件变量属于等待原语，用于等待某个条件成立后唤醒阻塞的线程。条件变量与互斥量一起使用，条件本身由互斥量保护。Java Object内置了条件变量wait(),notify(),notifyAll()。
pthread_cond_wait(),pthread_cond_signal(),pthread_cond_broadcast（Unix），从函数的命名就可以看出其大致作用。
根据陈硕的总结，条件变量的正确使用方式：
对于wait端：
1.必须与mutex一起使用。
2.在mutex已上锁时才能调用wait()。
3.把判断布尔条件和wait()放到while循环中。
第三个条件主要是为了防止spurious wakeup，既虚假唤醒。因为pthread_conf_wait能被除了pthread_cond_signal(),pthread_cond_broadcast外的其他信号唤醒。需要再wait后再次检查，同时也是为了避免错过一次条件变量后永远的等待下去。
对于signal端：
1.一定不要在mutex已经上锁的情况下调用signal。
2.在signal之前一般要修改布尔表达式。
3.修改布尔表达式通常用mutex保护。
4.注意区分signal和broadcast：“broadcast通常用于表明状态变化，signal通常用于表示资源可用”。
自旋锁
自旋锁与互斥量类似，但它不是通过休眠使进程阻塞，二是在获取锁之前一直处于忙等。既一直占用CPU资源直到锁被释放。
屏障
屏障主要用于多个线程之间的并行工作的协调。屏障允许每个线程等待，直到所有的合作线程都达到某个点，然后从该点继续执行。
信号量
这个在《unix环境高级编程》中没有提及，在《操作系统》中有论述。
信号量可作用与进程间合作，以及多线程的同步。
一个进程可以被迫在某一个位置停止，直到接收到某一个信号。为了发信号，需要使用一个称为信号量的特殊变量，可以看做一个具有整数值得变量。其中只允许信号量取0和1的称为二元信号量。非二元信号量常称为计数信号量或一般信号量。
一般在信号量上定义三个操作：
1.一个信号量可以初始化成非负数。
2.semWait操作使信号量减1。如果值变为负数，则执行semWait的进程或线程被阻塞，否则继续执行。
3.semSignal操作使信号量加1。如果值<=0，则被semWait阻塞的进程被解除阻塞。
信号量需要队列保存阻塞在信号量上等待的进程。至于进程按什么顺序移除，最公平的是先进先出，采用此策略的为强信号量。没有规定顺序的为弱信号量。
互斥量和二元信号量的主要区别在于互斥量的加锁和解锁必须由同一线程分别对应使用，信号量可以由一个线程释放，另一个线程得到。至于用于互斥和用于同步的说法，十分牵强。
陈硕关于信号量的建议是不用。
因为可用条件变量加互斥量完全代替，另外还需要担心计数值需要和自己的数据长度常常保持一致的问题。
死锁
死锁大概已经被讲烂了，我也不想再搬运了。坚持使用Scoped Locking，死锁的时候好检测。
补充一个坑爹坑爹坑爹坑爹的问题：系统如何将一个信号通知到进程？
前面讲过信号了，为什么又问一遍？这个问题有什么特殊的地方么？
内核给进程发送信号，是在进程所在的进程表项的信号域设置对应的信号的位。