4.1.3 锁

作者: Jim Mauro; Richard McDougall 出处:机械工业出版社华章公司 　2007-09-24 14:15　   砖    好    评论  条 　进入论坛

阅读提示：《Solaris 内核结构》（第2版）第4章主要介绍的是进程间通信（IPC），本文讲了用来确保正确性：槽锁（slot lock）、命名空间锁（namespace lock）以及p_lock（检查资源控制时所必须的）的三把锁。

4.1.3 锁

三把锁（或者说三类锁）用来确保正确性：槽锁（slot lock）、命名空间锁（namespace lock）以及p_lock（检查资源控制时所必须的）。它们的顺序是：

一般来说，命名空间锁用来保护该命名空间中的分配、删除，ID枚举以及ID表大小的调整。特别是，
ipc_service结构体中所有字段的写权限；ipc_service结构体中除了ipcs_tabsz（表大小）和ipcs_table（表指针）以外的所有可变字段的读权限。

可见对象的kipc_perm结构中ipc_avl、ipc_list字段的读/写权限（即，已经从命名空间中删除的对象没有这个限制）；表各项中的ipct_seq和ipct_data的写权限。

槽锁本身并没有什么意义（除了调整表大小）。较大的用处是ID锁的抽象概念——“虚拟锁”，也就是对象ID当前散列指向的槽锁。

一个ID锁能保护具有此ID的所有对象。正常情况下，仅有一个这样的对象：已被锁住的槽所指向的对象。然而，如果某对象已经从命名空间中删除，但是还存在对它的引用（例如，已经被RMID删除的附加共享内存块），那么它仍可以继续使用与它最初ID相关的锁。由于这样导致了越来越多的竞争问题，因此需要已删除对象的ID锁的操作是很少见的。

特别地是，ID锁除了保护对象结构的内容外，包括嵌入的kipc_perm结构的内容（除了那些被命名空间锁保护的字段），也保护它所在槽的ipct_seq和ipct_data字段（毕竟，它实际上是槽锁）。
前面我们说到表的大小是可调整的。为了避免每次ID查询占用一个全局锁，我们采用了一种机制，这种机制与使用文件描述符（见14.2.1节）时所采用的机制很类似。请注意，序列号和数据指针是由命名空间锁和它们的槽锁共同保护。当进行表大小调整时，会发生下面的操作：

1.分配一个新表。
2.占用全局锁。
3.原有的槽按照次序都被锁住。
4.新槽的前半部分被锁住。
5.所有表项复制到新表中，并从旧表中清除。
6.更新ipc_service结构，使其指向新表。
7.更新ipc_service结构，表尺寸变为新表的大小。
8.丢弃所有的槽锁（包括旧锁和新锁）。

由于槽锁是嵌入在表中的，所以ID查询和其他需要占用槽锁的操作，都需要确认所占用的锁不是废弃表的一部分。为了确认这一点，我们在放弃对表指针引用和使用锁的前后都会检查表的大小：如果大小发生变化，锁必须被丢弃并重新获取。正是这个附加的工作将ID锁与槽锁区分开来。

因为我们不能保证线程不会访问旧表的锁，所以它们从来不会被释放。为了防止出现内存泄露的虚假报告，指向废弃表的指针被存储在一个新表中，见第5步。（理论上来说，ipcs_destroy会删除废弃表，但是它仅在失败的_init函数中被调用；即，当什么都没有时才调用。）

回书目   上一节   下一节