摘要： 资源获得2.1 Lookup模式 Lookup（查找）模式描述了如何通过使用查找服务作为中介实例来发现和访问资源（不管资源是本地的还是分布的）。1.问题 资源提供者可能提供了一个或多个资源给资源使用者。随着时间的流逝额外的资源可能会增加出来，或者存在的资源可能被资源提供者移走。资源管理者发布存在资源的可获取性的一种方式是以一定的时间间隔向感兴趣的资源使用者发布广播消息。这样的消息必须每隔一段时间就发布一次，以确保加入系统的新的资源使用者知道可用的资源。相反，资源使用者也可以发送广播消息请求所有可用的资源提供者响应。一旦资源使用者从所有可用资源提供者处获得了回复，它就可以选择其所需要的资... 阅读全文

摘要： 5.5线程特定的存储器（Thread-Specific Storage）1.问题 为了避免竞争条件、资源耗尽和死锁多线程应用程序需要复杂的并发控制协议，从而难以编程。由于存在加锁开销，所以多线程应用程序的性能往往比不上单线程应用程序，事实上它们的性能可能更糟，特别是在多处理平台上。在并发程序中有两个强制条件： 1）多线程应用程序应既容易编程又高效。特别地，对逻辑上全局的但物理上局限于一个线程的数据的访问应是原子的，且不会导致对每次访问的加锁开销。 2）许多遗产库和应用程序最初是在单一控制线程的假定下编写的。因此它们常常在方法间通过诸如errno的全局对象隐式地传递数据，而不是显式地... 阅读全文

摘要： 5.4领导者/追随者（Leader/Follower）1.问题 多线程是实现并发处理多事件的应用程序的一种常用技术。然而，很难实现高性能的多线程服务器应用程序。这些应用程序通常处理大量同时到达的多类型事件。为了有效地处理这种问题，有三个强制条件必须解决： 1）服务请求可以来自为每个已连接的客户机分配的多事件源（如多TCP/IP套接字句柄）。因此，一个关键设计强制条件是在线程和事件源间确定有效的多路分解关联。 2）为了将性能最大化，必须尽量减少引起与并发有关的开销。（如语境切换，同步化和缓存一致性管理）。特别地，为在多个线程间传递的请求动态分配内存的同步模型会在传统的多处理器操作系统... 阅读全文

摘要： 5.3半同步/半异步1.问题 并发系统通常既包含异步处理服务，又包含同步处理服务。系统程序员有充分的理由使用异步特性改善性能。异步程序一般更高效，因为可以直接将服务映射为异步机制，如硬件中断处理程序或者软件信号处理程序。 相反，应用程序员也有充分的理由使用同步处理简化他们的编程强度。通常同步程序更简单。因为可以限制某些服务在处理序列中的良好定义的点上运行。 因此，在定义一个既有同步又有异步执行服务的软件体系结构时，必须解决两个强制条件： 1）该体系结构应该这样设计：需要同步处理的简易性的应用程序开发者无需考虑异步的复杂性。同时，必须将性能最大化的系统开发者不需要考虑同步处理的低... 阅读全文

摘要： 5.2监视器对象1.问题 许多应用程序包含其方法被多个客户机线程并发调用的对象。这些方法通常修改其对象的状态。因此，为了使这些并发应用程序能正确地执行，有必要对对象的访问进行同步和调度。对于这个问题，必须考虑四个强制条件： 1）为了事务分离并避免对象状态不受控制地修改，面向对象编程人员习惯于只通过对象的接口方法访问对象。扩展这种面向对象编程模型以避免对象的数据不受控制的并发修改相对比较直接。因此对象的接口方法应该定义它的同步边界，在同一对象中某一时刻仅有一个方法能处于活动状态。 2）如果客户机必须显式获取和释放低层同步机制，如信号灯、互斥或条件变量，那么并发应用程序将更难进行编程。... 阅读全文

摘要： 并发模式为在多线程或进程间共享资源而设计的2种模式： ·主动对象设计模式将方法执行和方法调用分离开来。目的是加强并发和简化对驻留在自身控制线程中的对象的同步访问。 ·监视器对象设计模式同步化并发方法的执行，以确保同一时刻在对象内部只有一个方法运行。它也允许对象的方法协作调度方法的执行顺序。下面2种模式定义了高层并发体系结构： ·半同步/半异步体系结构模式将并发系统中的同步和异步进程分离，简化了编程而又不影响性能。该模式引入两个通信层，一个处理同步服务，另一个处理异步服务。还有一个排队层协调异步层和同步层服务之间的通信。 ·领导者/追随者体系结构模式提供了 阅读全文

摘要： 4.3线程安全接口（Thread-Safe Interface）1.问题 多线程组件通常包括多个可被公共访问的接口方法以及可以改变组件状态的私有方法。为了避免出现竞争条件，可以使用一个组件内部的锁对访问其状态的接口方法调用串行化。尽管当每个方法都自包容的时候，这种设计方法能很好地工作。但组件方法可能会相互调用完成计算任务。如果是这样，在多线程组件中有以下几个强制条件尚未解决，它们使用了错误的组件间方法调用的设计方法： 1）应该使线程安全组件避免“自死锁”。当一个组件方法在该组件中获得一个非递归锁，然后调用试图获得同一个锁的另一个组件方法时，会发生自死锁。 2）为了避免出现对组件状态... 阅读全文

摘要： 4.2策略化加锁（Strategized Locking）1.问题 运行在多线程环境中的组件必须保护其临界区不被客户机并发访问。同步机制与组件功能的集成需要解决以下两个强制条件： 1）不同的应用程序可能要求不同的同步策略，如互斥、读写锁或信息灯。因此，应该可以按照具体应用的需求定制组件的同步机制。 2）加入新的功能和隐错修正应很容易。特别为避免“版本混乱”应始终将这些变化一致地自动地应用于组件系列的所有成员上。2.解决方案 将组件的同步特性变成“可插”的类型，用这种方式将组件的同步特性参数化。每种类型将特定的同步化策略对象化，同步策略包括互斥、读写锁、信号灯或“空”锁等。将这些... 阅读全文

摘要： 同步模式 C++惯用法定界加锁（Scoped Locking）能确保当控制进入到某一个范围时，自动获得锁，而当控制离开该范围时，自动释放锁，不管从该范围返回的路径是什么。 策略化加锁（Strategized Locking）设计模式是策略模式的一种特例，它把同步机制参数化，这一机制保护临界区免受并发访问。 线程安全接口（Thread-Safe Interface）设计模式使加锁的开销减至最少，确保组件内部的方法调用不会因为要再次获得一个组件已经拥有的锁而“自死锁”。 如果程序执行期间临界区代码只能以线程安全的方式获得一次锁，双检查加锁优化（Double-Checked Lock... 阅读全文

摘要： 3.4接受器 - 连接器（Acceptor - Connector）1.问题 在面向连接的网络化系统中，应用程序通常包含相当大量的用于建立连接和初始化服务的配置代理。这些配置代码大多独立于服务对在连接传输端点之间交换的数据所进行的处理。因此配置代码与服务处理代码之间紧密耦合是不理想的，因为这样不能解决以下四个强制条件： 1）它应该很容易地改变连接角色，以支持不同的应用特征。 2）应很容易地增加服务，服务实现和通信协议的种类，而不影响已有的连接建立和服务初始化配置代码。 3）连接建立和服务初始化策略的改变要比应用程序实现的通信协议和服务的改变频率少。 4）对大规模网络化系统，应能通过使用高级的操 阅读全文