Sun公司开源游戏服务器Project Darkstar Server——（Sun game server , 简称 sgs）学习笔记（四）：任务和管理者

Tasks and Managers任务和管理者：

从PDS 应用开发者的角度来说，PDS 应用执行在一个封闭的单线程的，事件驱动模型中。通过句柄传递事件实现编码对数据的修改，对于编写代码的程序员来说就好像是在修改自己的数据一样。因此，执行程序是一个平稳竞争和弱死锁的。在大多数情况下，没有必要

通过的代码，事实上，在管理数据对象是经常使用synchronized 关键字容易产生不稳定的bug。

    事实上，这个系统有很多的线程用于控制异步的事件的处理。这些控制线程叫做任务。这个系统对每个任务的访问数据进行监视。当一个冲突升级时，一个任务正在执行，计划任务会在之后重新尝试执行，这样任务就可以竞争，并且脱离死锁的危险。任务创建PDS 的关系者。一个PDS 应用的通过管理器来影响PDS 环境和外部世界的操作。在系统中一共有三种标准的管理者。实际上，外加的管理者可以通过编码添加到PDS 环境中。标准的管理者如下：

（1）       Task Manager任务管理者

一个PDS 应用可以使用任务管理者排列其自己的任务。任务可以被分为立即执行任务，延迟执行，空闲时间执行。在没有其他任务条用任务的时候任务创建。排列子任务的任务叫做父任务。多个子任务被同一个父任务排列执行，成为兄弟任务。

（2）       Data Manager数据管理者

PDS 应用可以使用数据管理这创建和访问持久化数据，生成的Java 对象叫做管理对象。PDS应用是由其自己生成的一个管理对象。PDS 应用由管理对象组成，这个在下面的“管理对象和管理关系”中已经全面的解释了。

（3）       Channel Manager通道管理者

PDS 应用可以使用通道管理者创建和控制发布/订阅模型的数据，这些数据通道用于在客户端的组和服务器间进行通信。

一个PDS 应用可以通过应用程序的上下文访问核心的PDS 方法，这个上下文提供了联系多个管理者的关系和方法。

 

 

Task Ordering任务顺序

任务（管理器）由客户端触发的事件在PDS 系统中是按顺序执行的。由同一个客户端产生的比较早到达的事件完成之前，任务管理器不会立即执行相同客户端传递来的事件(而是会等待前面的事件处理完成之后才会再执行后面的事件)。一个子任务执行的顺序是依赖于其父任务，而不是根据其自己的处理顺序。这就意味着在父任务未完成之前，子任务是不会开始执行的。

要点：在系统中没有其他的顺序。特别的，不同用户的任务事件开始执行的顺序与他们到达服务器的顺序有关系。

Task Lifetime任务的的生命周期

任务应该是一个生命周期比较短的，这样就不会发生访问的阻塞，当一个资源需要花费大量的时间时，它就应该由其他的任务来完成。PDS 系统设置了一个任务的执行的最大时间(默认值是100 毫秒).任何在这个时间内没有完成的任务都会被终止。如果你有一个任务运行的时间很长，有两种办法来解决它的执行时间问题：将其拆分成多个链式的子任务，每个Handler 处理这个问题的一个操作，并将下一个要执行的任务放在要执行任务的队列中。这个就是注明的状态机模式。将比较耗时的计算移动到一个自定义的管理器中，当计算完成时会返回一个结果。每种方式都有其有利或不利的地方。第一种方式用于解决比较简单的问题，但会使他们陷入严重的困扰之中。要仔细的检查在每个任务在结束时的状态，因为没有正确的执行顺序，用于指明下一步要怎样操作。一个特殊的情况是，这个问题的哪个部分被拆分并平行的分离出来。在这种情况下，完成这个任务的时间会因为链上的任务时间会减少。然而这些平行的任务连，彼此之间没有顺序，所以处理他们的工作的线程也是彼此独立的。第二个阶段对与服务来说比较简单，他们没有被完整的分成小的不相关的组件；然而，他需要自己写一个PDS 的管理者，并且安装到PDS 环境中。（关于写一个自定义的PDS 管理器的方法已经单独的在《怎样扩展PDS 系统》的文档中单独的说明了。）一个特别重要的情况是编写一些需要条用系统模块，并且需要消耗执行时间的一些方法。他们需要自定义一个管理器，这样就降低了PDS 应用的健壮性。这也暗示了那些有两个不同客户端生成的任务不需要按他们客户端的生成顺序来执行。实际上，这在网络游戏中是不正确的，除非指定一个特定的程序让它这样的执行，因为在两个客户端通信的时，这些简单可变的信息对于服务器来说是按顺序到达的。