内存映射文件与命名管道的速度谁快
我有两个进程，需要进行进程间通信，采用请求/响应的机制。
由于请求/响应的次数，1秒内估计有1万次，现在用的是命名管道，发现速度不行。当然这个时间也跟另一个进程的数据处理时间有关。请问有没有更快的方式，比如内存映射文件是不是更快呢。

[解决办法]
应该不会更快。内存映射文件通常的目的：用操作内存的方式，操作磁盘文件的，尤其是是针对文件比较大的时候。

直接用共享内存试试吧，如果还不行估计常规的办法就木有了。
[解决办法]
那用共享内存吧, 申请个500M的, 里面建个环形队列, 做一个进程共享mutex+cond, 做lock+cond_wait+cond_brodcast支持多进程并发写多进程并发读，保证无死锁。
[解决办法]

探讨

响应方确实具有多个线程，估计最大时会有60个线程，我现在是直接用CreateThread来创建线程的。请问这种方法，是不是较慢。是不是你说的线程池会快一些呢。
另外消息队列你是指通信上用消息队列吗？
我试了一下，主要时间浪费在响应方的数据处理上，通信时间很少，数据处理上时间的增加，主要是加入了线程同步，我用的是临界区。不用线程同步，程序就会异常，请问有没有好的解决方案


引用 3 楼……

[解决办法]

探讨

响应方确实具有多个线程，估计最大时会有60个线程，我现在是直接用CreateThread来创建线程的。请问这种方法，是不是较慢。是不是你说的线程池会快一些呢。
另外消息队列你是指通信上用消息队列吗？
我试了一下，主要时间浪费在响应方的数据处理上，通信时间很少，数据处理上时间的增加，主要是加入了线程同步，我用的是临界区。不用线程同步，程序就会异常，请问有没有好的解决方案


引用 3 楼……

[解决办法]
命名管道走网络协议栈，速度应该慢些

内存映射擅长随机操作文件，能大大降低操作复杂度，顺序操作的话（不用seek跳来跳去），普通I/O也不麻烦，只是相当于多一层缓冲，效率略低

线程是太多了，尽量用线程池