钢筋混凝土的UNIX C编程技巧（一、内存映射表）[原创]

linux_newbie

你这个应该只能在单进程且单线程环境中使用吧？
但是你又用到了共享内存，应该是特意用于可以并发的。

如果都是只读操作，例如你的FetchMapGGXTCS，这个到没有问题。
但是我看到你有一个函数UpdateMapGGXTCS，这个东西如果不提供保护，多进程更新同一个记录马上出现问题。

如果要上锁，可能要考虑读写锁，可能为了效率的原因，不能锁定整个表，还要实现细粒度的锁。这个复杂度马上提升10倍都不止。
还是让数据库去干吧。

linux_newbie

方法是在内存中开两片同样的区域,一边用于应用中的查找,另一边在更新,可以指定更新的间隔时间.更新完毕后将两块数据的角色对换.

我倒是有点疑问。那个用于更新的是不是允许并发呢？如果允许，那么同样需要锁定机制。如果对整个区域加锁，那么任何更新无法同时运行，即使它们是更新不同的记录。如果需要细粒度的锁，那么复杂性就提升了。

既然都需要锁，如果为什么不直接使用一个区域，不过是使用读写锁而已。

而且更新完毕后两块数据的角色对换，这个操作也必须是一个原子操作才行。

总之，麻烦。

linux_newbie

在同一时间肯定只有一个线程(或进程)访问用于更新的那块空间

你要是这种情况的话，我估计只需要多一块内存可以容纳单条记录的就可以了。

先在这个私有内存中更新，填好后，直接将Read List中的某个指针“突然”指向这个刚刚填好的结构就可以了。不过这要求你最好使用单链表。一般32位机器对一个Int赋值都是原子操作。

linux_newbie

FH的帖子很有启发性，确实如果只在某个时刻由一个进程进行一次更新的话，这样当然避免了并发，但是你如何又保证这些被你缓存了的修改能够最后提交到数据库中去呢？例如在你更新的那个时刻之前OS crash了，内存属于volatile storage，掉电后信息丢失，client所做的修改如果仅仅只buffer保存在内存中，那么全部修改将丢失。或者你这个表中存储的信息根本就无须保证这种语义？

这就是我上面说到的一致性问题了。楼上也用不着大惊小怪的，仔细想想数据库是怎么做的，不是一样的道理吗？

数据库一般都是通过stable storage来实现一致性。通常也就是指硬盘。一般数据库都有log，有一套recovery机制，在内存掉电、系统crash的情况下，可以根据stable storage来恢复。可能接下来再问，硬盘也可能坏，怎么办？一般再使用物理冗余的方式，例如硬盘阵列。阵列坏了？首先这个错误应该马上被检测到，然后系统可以拒绝服务。如果还检测不出来继续运行，可能会混入错误的数据，这种概率太小，那就祷告吧。

linux_newbie

也别Hash，qsort了，我还是不明白。
你不是使用共享内存吗，那么你这个共享内存应该只在一台服务器上吧？应该不会上海、杭州都有备份的共享内存，而且它们之间都进行实时的同步更新吧。

既然你使用共享内存，地震这些先不说，由于系统、程序故障造成宕机、crash而内存丢失的情况你如何处理？这个概率可不小。

我估计你的备份是数据库的备份，可是这些在共享内存中的东西，按照你的说法，不是要到晚上才更新数据库吗？那么如果下午程序crash了，上午那些更新是否就丢失了呢？