第三章分布式系统的同步-Read.doc

PAGE 1 PAGE 16  FILENAME 3796910-5902c7950ed4f.doc 共  NUMPAGES 16 页 第三章 分布式系统的同步 在第二章，我们已介绍了分布式系统中进程之间是如何进行通信的，使用的方法包括分层协议、请求/应答消息传输机制（包括RPC）以及成组通信。尽管通信非常重要，但它并不是分布式系统的全部内容。与此紧密相关的是进程之间如何协作及如何彼此同步。比如说，在分布式系统中临界区如何实现，资源如何分配。本章将研究这些内容及其它与分布式系统中进程合作及同步有关的一些问题。 在单CPU系统中，临界区、互斥和其它同步问题经常使用信号量、管程等方法来解决，这些方法在分布式系统中并不十分适用。因为它们必须依赖于共享存储器的存在。比如，有两个进程通过使用信号量而相互作用，它们必须都能访问信号量。如果它们在同一台机器上运行，它们能够共享内核中的信号量，并通过执行系统调用访问它。但是，如果它们运行在不同机器上，这种方法就不适用了，而需要其它技术，甚至看似简单的问题，比如判断事件A在事件B之前还是之后发生的问题也需要认真考虑。 由于时间在一些同步方法中起着重要的作用，我们将先从时间以及它的测量入手，然后介绍互斥和选举算法，之后我们再研究一种称为原子(基本)事务的高层同步技术，最后，介绍分布式系统的死锁问题。 3.1时钟同步 分布式系统的同步比集中式系统的同步要复杂些，因为前者必须使用分布式算法，如果像集中式系统一样，在某地收集有关系统的有关所有信息，然后让某个进程分析并做出决定，是不切实际的。一般说来，分布式算法有如下性质： 1．相关信息分散在多台机器中。 2．进程决策仅仅依赖于本地信息。 3．系统中单点故障应该避免。 4．没有公用时钟或其它精确的全局时间资源存在。 前三点都说明在一处收集所有信息并对它进行处理是不可接受的。比如，资源分配（以一种无死锁的的方式分配），向单一的管理进程发送所有I/O请求，由它来检查它们，根据表中的信息准予或拒绝请求是不实际的。在大系统中，这种解决方法会给某个进程带来太重的负担。 进一步而言，像这样，一个单点故障就会造成系统不可靠。最理想的情况是，一个分布式系统应该比单机系统更可靠，一台机器崩溃不影响其它机器的继续运行，我们最不希望的是，一台机器（例如：资源分配器）的故障使大量其它机器（它的用户）停滞不前。不通过集中而获得同步所使用的方法应该与传统操作系统所用的方法不同。 上述的最后一点是十分关键的，在集中式系统中，时间的概念很清楚，当进程想知道时间时，它使用系统调用，由内核提供。如果进程A询问时间，之后进程B也询问时间，B得到的时间值就应该大于或等于A所得到的时间值，但一定不会小于A得到的时间值。在分布式系统中，获得时间上的一致是并不容易的。 考虑一个简单的例子，在缺少全局时间时的UNIX下的make程序。一般，UNIX系统中一个大程序通常可被分割成多个源文件，如果某个源文件发生变化，只需将该文件重新编译即可，而不需要对所有的文件进行重编译。如果一个程序由100个文件组成，这样修改一个文件不需重新编译其余的文件，将大大提高编程人员的工作效率。 Make程序所使用的这种方法很简单，当编程者修改完所有的源文件，他启动make程序，看一下源文件和目标文件最后一次修改的时间，如果源文件INPUT.C时间为2151，而相应的目标文件INPUT.O时间为2150，make就知道INPUT.C在INPUT.O创建后被改动过。因此，INPUT.C必须重新编译。相反，若INPUT.C时间为2144，而INPUT.O时间为2145，就不必再重编译了。make检查所有的源文件并找出哪一个需要重编译，调用编译器重新编译它。 现在设想一下，在没有统一时间的分布式系统中会发生什么情况。假设OUTPUT.O的时间如上为2144，紧随其后OUTPUT.C被修改，但是由于它所在机器上的时钟略慢，造成OUTPUT.C时间为2143，如图3.1所示。make将不再调用编译器，最终可执行的二进制程序将包括由老的源文件和新的源文件所产生的混合目标文件，这样可能将不能再正常执行。编程者将为此去检查源代码以寻找错误所在，而搞得精疲力尽。 图3-1 当每台机器有它自己的时钟时，一个发生于另一事件之后的事件可能 会被标记一个比另一个事件更早的时间 既然时间是人们考虑问题的基础，然而正如我们看到的，没有同步时钟的后果是如此可怕，我们就先从这样一简单的问题开始研究