递归互斥量解决死锁问题
一、递归互斥量
一般情况下，我们在同一个线程中对同一个互斥量加两次锁，就会死锁（自我死锁）。如果将互斥量类型属性设置为递归类型 PTHREAD_MUTEX_RECURSIVE 就不会出现此问题。
递归互斥量内部维护着一个计数器，当互斥量未上锁时，计数器值为 0。只有计数器为 0 的情况下，线程才能够获得锁。只有获得锁的线程，才能持续对互斥量加锁，每加一次锁，计数器的值加 1，每解一次锁，计数器的值减 1.
二、 死锁的概念
日常生活的死锁：我们只招有工作经验的人！我没有工作经验怎么办？那你就去找工作啊！ 假设有2个互斥量M1、M2，2个任务A、B： A获得了互斥量M1 B获得了互斥量M2 A还要获得互斥量M2才能运行，结果A阻塞 B还要获得互斥量M1才能运行，结果B阻塞 A、B都阻塞，再无法释放它们持有的互斥量 死锁发生！
三、自我死锁
假设这样的场景： 任务A获得了互斥锁M 它调用一个库函数 库函数要去获取同一个互斥锁M，于是它阻塞：任务A休眠，等待任务A来释放互斥锁！ 死锁发生！
四、用递归互斥量解决死锁问题
两个任务经过精细设计，运行流程如下所示： A：任务1优先级最高，先运行，获得递归锁 B：任务1阻塞，让任务2得以运行 C：任务2运行，看看能否获得别人持有的递归锁：不能 D：任务2故意执行"give"操作，看看能否释放别人持有的递归锁：不能 E：任务2等待递归锁 F：任务1阻塞时间到后继续运行，使用循环多次获得、释放递归锁 递归锁在代码上实现了：谁持有递归锁，必须由谁释放。
