system v共享内存删除问题

float001

前段时间工作需要，对现有系统的共享内存进行改造，需要做到一下几点：
1、共享内存实时更新不影响现有进程
2、不能存在进程等待共享内存的情况

鉴于上面几点曾想过很多种办法，有共享内存复制、进程任务对列等等，但是不能很多好解决这个问题。最后无奈对共享内存的一些性质进行了测试，最后结果却出乎意料，要满足上面的要求，linux内核已经完全可以解决了，结果如下：
1、测试异常退出，共享内存连接数是否减少  -- 测试结果减少
2、有连接的时候，删除共享内存，是否能删除成功  --有连接时，共享内存没有删除，状态设置为dest,key值置为0，已连接的进程可以继续访问 其他进程无法连接
3、共享内存状态为dest时，在创建一次会出现什么情况？ -- 状态为dest的共享内存不变，系统会根据key值重新生成可用的shmid
4、同一个key值，在系统中没有用此key值生成的异常共享内存或已删除的共享内存，则每次的shmid是相同的

以上

卖萌犯法

我们做过这样的东西，如果我理解不错的话，你是想动态替换共享内存吧

我们做的方式是：
1.创建一个多进程共享的内存，并创建一个独立于所有进程的，共享内存的管理者进程（或某个系统主要进程的线程）
2.在每个需要共享内存的进程或线程中，创建一个该共享内存的镜像，改镜像与共享内存的变更是异步的，由信号处理函数更新
3.设置版本号和信号处理函数，用于同步共相内存和及其在各进程中的镜像
4.当共享内存被删除，替换或结构变更时，组播信号给整个进程组，利用信号处理函数，对比版本号，进行更新操作

float001

回复 2# 卖萌犯法


    这种方式我们也考虑过，但是以下几点让我们放弃了
    1、共享内存镜像的空间问题，我们一个共享内存就要17g左右，镜像的话会增加内存开销
    2、编程的复杂度提高不少
    3、每次进程开始时都要进行共享内存检查，如果需要同步的话，可能会造成进程等待，实时性降低
   
   所以最后测试发现这些问题，系统内部已经解决了，代码也不用改就可以实现了，就是在共享内存修改时，如果有进程使用会造成内存的使用峰值，所以我们尽量在进程不用内存时进行共享内存更新。
   

卖萌犯法

回复 3# float001

好吧，闲时更新也是个好办法。不过，这需要附加性能监视机制，也许你们已经有现成的实现了。

对于1. 不知道你们这个项目是什么需求，为何会使用这么大段的共享内存，或许是用于文件和图像处理？如果不要求整段内存更新，可以将内存分为多段管理，不需要对所有内存都建立镜像，只对那些频繁更新的建立镜像即可。

对于2. 其实并不复杂，如果使用请求代理模型作为设计结构的话。

对于3. 使用异步更新可以减少同步和阻塞，应当是提高效率的。