就在昨天,就在我们的项目要结项的时候,一个影响力不亚于’广岛原子弹’的bug出炉了,蒙蔽我近一个月的问题终于被澄清了,不过为时已晚,项目即将上线,如果想彻底地解决这个问题,需要对整个系统的实现架构作调整,目前能做的只是’亡羊补牢’了。

这里先简单的说一下问题的原因吧!熟悉Unix编程的人都知道有’共享内存映射’这回事儿,我们的问题恰巧就出在对’共享内存映射’的使用不当上。由于我们使用的底层库采用的是mmap的匿名共享内存映射,所以这里例子中的共享内存映射默认就指使用mmap的映射。我们可以利用下面的一个例子简单说明一下我在项目中遇到的问题,实际上看完这个’精简版’之后你会认为这很简单亚,怎么会让你困惑一个月,的确是这样不假,但是如果加上了繁杂的上下文后,找起来也并不是件容易的事情。

假设我们有这样的4个进程,它们的亲缘关系是这样的:A是爷爷,B、C是兄弟,并同为A的儿子,而D则是孙子,是B的儿子,用图表示如下:
A
| —- B
|         |—-D

| —- C
问题就出在D利用mmap映射到匿名设备上后,将返回的起始地址赋值给一块由A创建,B、C、D都继承并能访问到的共享内存中的指针。C的任务是读写这块由D创建的这块儿共享内存中的数据。明眼人一眼就可以看出,C是访问不到这块D映射的共享内存的,即使C知道那块内存在D中的地址,但是由于C没有映射,在C进程空间中即使访问那个相同的地址,实际上访问的虚拟内存页也是不同的,最终的结果就是dump core。不光是C就连B、A也都无法访问D的那块共享内存,原因这里不详说,任一本质量上乘的有关Unix编程的书都会讲到这一点。

出现这样的问题,自己有推卸不掉的责任,先撇开责任不谈,反思自己在查找bug过程中的行为,我觉得有两个问题是今后需要改正的:
1、始终质疑别人的代码,导致在查找bug的时候戴上了’有色眼镜’,思维也发生了倾斜,把大部分时间和精力都花在查找别人的代码漏洞中,而忽略了对自己代码的细致地分析。不过这个过程到让我学了不少以前未接触的’知识领域’^_^。
2、测试时态度不够端正。其实项目负责人当初就对这块儿的可靠性有质疑,只是他当时也不能具体说明到底哪个地方的使用会出问题,回头看来自己在测试时测试用例不全,也是导致没有及时发现对症问题的一个重要原因,从而失去了走向查找出正确问题所在之道的机会!

问题既然发生了,那么我们如何来解决这个问题呢?我和leader一起想了若干种方法结果都被我们一一否决,最后拿出了一个折衷的方案,该方案虽然不存在上述问题了,但是它也让我们的系统不能完全满足用户的需求。这个方案说来也简单那就是采用’池策略’,而且这个池也是一个扩展性不好的池,也就是说我们在系统初始化的时候就预先映射完毕所有的内存,这样所有的A进程的子进程都会继承A的内存映射关系,从而解决上述问题,不过这样做实际上就给系统加了一个限制,容量上的限制。

在接下来的另一个类似需求的项目中我们还需要使用这样的架构,而且这个延续的项目需要的系统容量更大,在这个系统中我们需要对整体的系统架构进行改动了,否则一旦出问题,就不再是’亡羊’就可以’补牢’的了!

目前部门内所有项目的架构基本上都是基于’共享内存’的,虽然’共享内存’是最快的IPC对象,但是它同样给系统带来进程同步性能低下、亲缘关系错综复杂等弊端,甚至于对于我们目前项目这样的需求都不能很好的支持。程序庞大,动一发而牵全身。当然对架构的改造也不是一朝一夕之事,需要的是魄力、时间和耐心,起码让我们的Unix程序符合K.I.S.S这种最适合Unix的文化,目前我们采用的这种架构还是比较臃肿的。

© 2006, bigwhite. 版权所有.

Related posts:

  1. APR源代码分析-信号篇
  2. APR源代码分析-整体篇
  3. APR源代码分析-设计篇
  4. 解疑sigsuspend
  5. 学习虚存-自上而下