多进程共享数据的弊端

kingluo 发布于 2015/06/10 11:26
阅读 580
收藏 0

@osdba 你好,想跟你请教个问题:

PostgreSQL是多进程程序,针对每个客户连接都创建一个子进程代理所有SQL操作,而这些SQL操作本身会对共享内存进行一些操作,甚至会加锁。我这里想延伸开来的是,多进程对共享内存读写的一些弊端。

进程IPC从有无OS干涉可以分为两类,有干涉的,例如文件锁,在进程退出后,OS会重置之;无干涉的,例如pthread API的进程模式、共享内存,如pthread_mutex_lock,这个锁只在共享内存设置一个位,如果进程退出,那么这个位的值会一直保留下去,从而让其他等待这个锁的进程永久等待。

再延伸来说,进程对共享内存的操作一般不是原子操作,例如在共享内存维护一个哈希表,那么对哈希表的插入操作起码包含对item数目的更新、bucket链表的更新等等,如果在这个过程中进程崩溃,留给其他进程的将是一个不完整的无意义的状态,而这种状态OS是不会对其还原的。

我也曾经编写过这种多进程程序,而为了规避以上问题,我选择的是由父进程或者守护进程统一代理所有写操作,而其他工作进程对共享内存只读,但并非所有多进程程序都适合这种模型,例如PostgreSQL,为了性能,每个客户进程都会去写共享内存,那么就不能不思考以上问题了。我曾经试过在某个客户进程处理SQL的过程中kill掉它,导致其他子进程永远等待在这个子进程遗留的锁上无法恢复,甚至共享数据处于一个无效状态中,导致系统工作不正常。

请教一下,您有没有相关的思考呢?这些问题的解决方案是什么呢?

加载中
返回顶部
顶部