libevent+多线程+pipe的死锁问题
每个线程都是一个libevent实例。线程间通信使用的是管道机制,在写端调用write()时,直接写入8个字节的消息指针。读端调用read()时,每次读取8个字节。现有A、B、C三个线程,C线程会生产消息由A线程处理,A、B线程之间会互发消息各自进行处理。
那么在业务高峰期处理大量数据时,可能会出现死锁问题。具体表现为:A线程当前正在处理一个消息,然后生成一个新的消息写入B线程,如果此时B线程的管道缓冲区满了,那么A线程调用write()写入B线程时,就会阻塞。又因为此时B线程此刻正在调用write()写入A线程的管道,由于C线程也在写入大量的数据到A线程的管道,所以如果A线程的管道缓存区满了,C、B线程也被阻塞。死锁便发生了。
![](https://i-blog.csdnimg.cn/blog_migrate/9764cc6936febf26b801932d1d819c81.png#pic_center)
因为管道的缓冲区大小是有限制的,业务高峰期时,管道缓存区满时导致阻塞很容易产生死锁。
该问题主要是因为对管道的使用不熟导致,因为线程间传递的实际是一个8字节的消息指针,我觉得直接写入8字节给管道,比「加锁写入线程队列,管道仅作为通知机制」更方便,于是没有采用线程队列的方式。
后参考了memcached源码,其使用管道,仅仅作为通知机制,每次写入时,只写入1个字节的数据,也就是字符c,真正的消息,实际上是加锁写入线程队列。
![](https://i-blog.csdnimg.cn/blog_migrate/8819b0acd2fba27fa02f99c9f00aa643.png#pic_center)
因为管道缓存区大小的限制,加锁写入线程队列,写入1个字节仅作为通知机制,对管道缓存空间的利用,相较于每次写入8个字节的消息指针,要高出8倍。其次,memcached一次性读取32字节再批量处理的机制,相较于,每次只能从管道read出8个字节然后进行处理,要高效的多。
![](https://i-blog.csdnimg.cn/blog_migrate/3a7806864dc486152922da54516ed44a.png#pic_center)
以前我也知道使用队列这种方式,但我优势认识不清晰,现在明白了。