11．2．6 抖动问题 写无效协义的一个潜在问韪就是抖动问题。抖 动指的是数据无效的时间超出了等待访问它的进程 的有效工作时间。例如，如果一个进程读的是一个 被另一进程反复修改的数据项，那么该数据项对读 进程而言总是无效的。
2．弱一致性 弱一致性模型可以避免有序一致性模型的通信开销。这个模型用同步模型 的知识来解决内存一致性问题，而程序看上去是在有序一致性模型下运行。例 如，如果一个程序的某一段是临界段，它就给这一段操作的数据加上锁，其他 进程由于互斥性不能访问这些加锁数据，DSM系统在进程离开临界段并解除 了锁以后，将这些修改传送给备份管理者。虽然在加锁期间，这些数据是不一 致的，但由于其他进程访问不到它，因而整个过程看上去就像是有序一致的。 一个DSM系统在一个同步模型下是弱排序的，当且仅当遵循同步模型规 则的所有软件在运行中表现出有序一致性。 11．2．4 修改问题 将一个进程所作的修改传送给其他进程时，有两种选择：写有效和写无效。 它们适用于不同的一致性模型，包括有序一致性模型。 1．写有效 当一个进程在本地修改了一个数据项时，它将修改值传送给拥有该数据项 的备份管理者，其他进程要从本地读出这个修改值来替代原来的值。为了允许 有多个读进程存在，有些进程可以在同一时刻修改同一数据项，这就是所谓多 个读者多个写者的共享。 能使用写有效方式的一致性模型要满足几个条件，首要条件是修改传送 (也称为组播)的顺序要合适。有序一致性要求采用完全有序组播，这一组播直 到修改消息被传送回来才算结束。所有进程都遵循这一修改的顺序，保证了整 个DSM的有序一致性。
11．2．2 同步模型 在DSM中，常常在某些变量之间建立一种约束，例如，a=b就是一 种约束，但这种约束并不稳定，如果两个或多个进程执行下列代 码:a=a+1;b=b+1；就会产生不一致性。假设a、b初值都为0，当进 程1将a置为1，在置b为1之前，进程2开始执行，它将a置为2，b置为 1，这时，约束条件被打破。解决这一问题的方法是将这段代码设计成临 界段。 为了使用DSM，必须有一个分布式同步服务保证DSM的同步性， 它包括我们熟悉的加锁和信号量。目前大多数DSM应用都利用同步模型 来减少修改值传送的数量，包含同步模型的DSM才能称为一个完整的 DSM。 11．2．3 一致性模型 DSM实现使用缓存来提高效率，在大多数情况下，为了保证效率， 数据是从本地缓存中取出的，但出现修改时，就要将这一改变传给其他 备份管理者。 除了缓存外，DSM实现可以采用写缓冲访问，它可以 减少因写操作而产生的通信开销。采用这些缓冲技术时，能否保证DSM 内存的一致性仍是-一个值得注意的问题，这种一致性称为内存一致性。 在实践中应用的DSM的一致性模型主要可分为有序一致性模型和弱 一致性模型。
在图11.2所示的例子中，ar=0,br=1的组合在有序一致性模型下就 不可能出现，因为进程1中的读操作与进程2中的操作次序发生冲突。图 11. 3是进程交错内存存取的例子。有序一致性的DSM要使用单一的服务 器来保存共享数据，进程在执行读写操作之前要向服务器发出请求，这样 服务器才能对这些操作进行全局排序。这样一种结构在实际实现中显然是 低效率的。
1．有序一致性 任何一个内存一致性模型所面临的中心问题都是：一个读操作和一 个写操作同时访问一个地址，读出的值应该是怎样的？最弱的极端是， 所有写操作都必须在读操作之前完成，而且备份管理者可以无限期地推 迟将修改传送给其他备份管理者。显然，这一模型太弱而不可能被采崩。 另一个极端是，所有写的值立即生效，读操作总是返回最近被修改 的值。但是，这一方案引来两个问题：第一，如果写操作和读操作都不 是在一个单独时刻发生的，那么“最近”这一定义就变得不明确。第二， 系统时钟在分布式系统中并不是同步的，因而判断一个读操作和写操作 谁先发生，变成一个难题 所幸的是，定义一个有用的、有实际意义的内存一致性模型在逻辑 上是可能的。最好和最重要的模型是有序一致性模型。在这个模型下， 任何操作都满足条件：由单个进程引起的读和写操作都以程序执行的顺 序发生，同时属于不同进程引起的内存操作也按一定的次序发生。 这些条件可以更具体地描述为：进程执行内存操作不能违反自身程 序的执行顺序，也不能破坏其他进程自身的内存操作次序。注意，只有 在整个DSM上的内存操作是有序的，才能保证有序一致性，而不仅仅是 在单个地址上满足内存操作的有序。
DSM这个工具主要应用于并行程序或分布式应用或群 组应用，这些应用都要求能直接访问每一个共享数据。例如， 具有一定程度一致性的内存镜像文件就是DSM的一种形式。 在分布式系统中，消息传递是不可避免的。在DSM中， 由于没有物理共享内存，DSM的运行支持只有通过消息传递 来通知各机器对DSM的任何修改。DSM中存在复制数据， 为了提高访问速度，每台机器都存有最近访问的共享数据的 备份。
1．2设计和应用 本节讨论DSM的设计和实现问题，这就是：DSM中的数据结构；应用层中 访问DSM的同步模型；保证被不同机器所访问的数据值的一致性的一致性模型； 不同机器上数据更新的修改问题；DSM应用中共享的颗粒性；抖动问题等。 11．2．1 数据结构 在应用中，DSM主要由三个方式组成：字节、共享对象、不可变的数据项。 1．基于字节方式 在Ivy,Mether系统中，采用的都是字节方式，它允许应用程序按照自己想 要的数据结构去共享内存，基于字节方式的DSM被访问时，如同普通的虚拟内 存。 2．共享对象 将共享内存当作一个对象集合的观点的好处在于，可以在对象操作这一级实 现同步。orea将DSM视为一个共享对象的集合，自动地将一系列操作施加在给 定的对象上。 3．不可变数据 Agora和Linda都将DSM看成是一个所有进程都可以读的不可变数据的集 合。在DSM中，进程通过对数据项进行替换来实现对数据的修改。例如， Linda使用了记录模型，在这里，记录是由字段组成的。宇段就是带类型的数据 项。进程将记录放人记录空间，从中读或取它们。选择记录时，进程要说明它要 访问的字段数和它们的值或类型。
11· 2 DSM的主要处理方式 1· 分布式共享内存主要有三种处理方式，分别是使用硬件，虚拟内存和库 支持。 1 ．基于硬件的方式 一些多处理器体系结构，依靠特殊硬件来装载、存储指令以完成DSM 的寻址操作及与远程内存节点的通信。在这些系统中，处理器群与内存节点 群通过高速网络相连，这种设计方式主要是为了使处理器的个数能突破10 个的极限或是使通信能在普通总线上得以完成。 2．基于虚拟页的方式 Ivy、Munin、Mirage、clouds、Choices、COOL以及Mether， 所有这些DSM应用都是虚拟内存方式，对每一个进入的进程而言，地址空 间的范围是一样的。在这些系统中，操作系统的内核负责DSM范围内的数 据一致性维护以及相关页的出错处理。 3. 基于库的方式 一些程序设计语言或语言的扩展，例如Orea和Linda支持DSM方式。 在这一类应用中，共享不是通过虚拟内存系统实现的，而是通过实时语言实 例间的通信来完成的。进程通过库调用来完成对DSM中数据的访问。这些 库函数可以访问本地数据项，也可以进行通信以完成数据一致性的维护。进 程还可以执行库调用以完成有关DSM消息的接收和发送。 基于虚拟页的方式应受到更多的关注。这主要因为它不需要在DSM中 采用特殊的结构。
11.1.1消息传递与DSM的比较 1．程序模型 （1）在消息传递模型中，发送进程将变量进行类似编 码方式的操作，传送出去后，接收进程要进行类似解码方式 的操作才能取出变量。相比之下，在共享内存方式下，进程 直接访问共享变量，而不需要进行编码解码操作。 （2）消息传递可以保护一个进程的私有地址空间不被 另一进程破坏，而DSM则通过导致另一进程访问失败来防 止错误的数据修改。 （3）如果消息传递采用的是异构计算机，在对变量进 行组织时就会遇到数据的多种表示问题，然而在DSM中， 数据的表现形式是统一的。 （4）在消息传递模型中，进程间的同步是通过将消息 分割传递来实现的，采用的技术如锁服务器应用等。在 DSM中，同步通过共享内存程序米实现，例如加锁和原语 通信。
1．2．5 颗粒性 与DSM结构有关的一个问题就是共享的颗粒性。在实际运行时，在 某一段时间，只有一部分数据被共享，如果一个进程访问并修改了数据， 就将整个DSM的内容传送给备份管理者，这样做显然是浪费。当一个 进程对DSM进行了写操作时，DSM实时支持系统需要传送哪些数据以 保证其他备份的数据一致性？ 在基于虚拟页的DSM中，硬件所支持的地址空间由多个页面及由 指向各个页面的页指针所组成的页表两部分组成。一个典型的页面大小 是8 KB，对于修改内容的传送而言，这是一个比较合适的数目。但是， 不论是整个页面被修改，还是页面中的一个字节被修改，传送的代价仍 是一个页面的内容。 ★使用页面大小为512或l 024个字节的小页面对整个系统的性能 并没有多大提高。 ★ 使问题复杂化的是，当页面较大时，进程总是容易为页面产生竞 争，因为随着页面大小的增加，几个进程访问的数据在一个页面的可能 性就越大。 ★在实际应用中，共享单元的选择取决于有效的物理页面大小。当 程序运行时，决定传送的页数的一个重要因素是数据在页面中的布局。
2．写无效 在多个读者一个修改者的情况下，写无效是常采用的一种 方式。在任何时刻，一个数据可能被一个或多个进程进行只读 访问，也可能被一个进程读或写。在只读访问方式下的数据可 以无限制地拷贝给其他进程，而当一个进程要进行写操作时， 它首先要通知其他进程该数据的备份无效，在通知完成时，再 进行写操作，其他进程因此可以避免读到过时的数据，因为在 写操作进行期间，无效数据是不能访问的。写操作完成后，修 改值被传送给其他进程，其他进程就可以进行数据访问了。 在写无效方式下，只有当读操作发生时，修改值才被传送，在 一次传送之前，可以有多次修改操作。反对这一方式的意义在 于，在写操作之前，要通知所有备份无效，这个开销太大。 在多个读者一个修改者的情况下，这确实是一个潜在的、 较昂贵的开销。但如果读／写比率足够大的话，多个读操作同ห้องสมุดไป่ตู้时进行而实现的并行性，使得这一开销得到补偿。当读／写比 率相当小，特别是一个读者一个修改者的情况下，写无效也是 很合适的，它的开销并不大。