libevent+多线程+pipe的死锁问题

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线程也被阻塞。死锁便发生了。

因为管道的缓冲区大小是有限制的，业务高峰期时，管道缓存区满时导致阻塞很容易产生死锁。

该问题主要是因为对管道的使用不熟导致，因为线程间传递的实际是一个8字节的消息指针，我觉得直接写入8字节给管道，比「加锁写入线程队列，管道仅作为通知机制」更方便，于是没有采用线程队列的方式。

后参考了memcached源码，其使用管道，仅仅作为通知机制，每次写入时，只写入1个字节的数据，也就是字符c，真正的消息，实际上是加锁写入线程队列。

因为管道缓存区大小的限制，加锁写入线程队列，写入1个字节仅作为通知机制，对管道缓存空间的利用，相较于每次写入8个字节的消息指针，要高出8倍。其次，memcached一次性读取32字节再批量处理的机制，相较于，每次只能从管道read出8个字节然后进行处理，要高效的多。

以前我也知道使用队列这种方式，但我优势认识不清晰，现在明白了。