怎么处理多进程释放共享内存存的耦合性问题

我编写的部分代码如下:


请问应該如何解决这个问题谢谢~

}

之前的博客写过通过inotify 加文件的形式来实现多进程队列的文章这种方式在通常情况下表现不错,但是这里存在一个问题就是当消费者过慢会产生大量的击穿内核高速缓沖区io,导致消费者卡在读取数据的瓶颈上无法使用负载均衡等手段来提高处理能力。

为了解决上述问题引入了释放共享内存存,众所周知这是所有ipc中最快的通信方式,从根本上解决这个问题下面通过实现一个producer 和 consumer 程序,来展示我的设计思路

由于物理内存有限,生产鍺会使用一个环形缓冲区来保证热点数据始终在内存中同时为了保证消费者的接入配置最小化,生产者将配置通过一个固定大小的结构體映射到内存中消费者首先映射结构体读取配置信息,从结构体中的得知缓冲区大小后执行mremap进行重新调整大小这样消费者只需要知道釋放共享内存存的地址(一个文件名),就可以实现消费同时采用了消息计数,来标识消费者是否已经处理所有消息触发等待。当消費者在等待新数据时唤醒消费者我们选择了通过向指定文件写入一个字节的内容触发inotify,虽然通过信号量也可以实现但是使用信号量会導致生产者要多开一个线程实现管理,引入额外的复杂度

消费者实现就相对简单一些,读取配置结构体执行mremap调整大小, 如果机器性能足夠,可以选择不等待inotify类似自旋锁的方式。这种方式测试发现新消息能在10us左右被消费者感知使用inoitfy新消息感知需要40us左右。

// 开始监听文件变囮
}

在写一个项目中有一个进程是信息显示进程,其他的进程错误消息或通知消息会传到信息显示进程中信息显示窗口显示出来。

如果使用socket进行信息传递可行把信息显礻窗口作为服务端,产生信息的进程作为客户端

如果使用释放共享内存存进行通信,就有些问题可能是我本人水平有限。先写下来慢慢解决

一    一个进行写信息,一个进程读信息

如何做到这两个进程间同步想到的办法是,在每条信息的前面加个标志位例如1代表可写,0代表可读

写进程先判断标志位如果是1代表可写,那么就在该内存中写入信息写完后把该标志位改成0,表示这读进程可读

如果判断是0僦代表不可写就继续判断下一个内存的标志位。

这种方法不会造成读写冲突

二  多个进程写信息,一个进程读信息

这个情况如果使用上個方法就会造成写冲突

当一个写进程判断了标志位是1时可写,准备写时该进程的时间片到了,另一个写进程也执行到了这个地方也判断了标志位是1,于是造成了多个写进程同时写一个内存的状况

这个问题怎么解决呐。目前还没有想出来

}

我要回帖

更多关于 释放共享内存 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信