DirectPlay Callback Functions and Multithreading Issues

作者：杨冰（源代码之光）
E-mail:iceryeah2000@163.com
创建时间：2002-10-24
最后修改时间：2002-10-26

备注：感觉这章翻译的不是很透彻，可能是因为多线程的知识比较欠缺

DirectPlay需要你注册几个回调函数来管理消息的响应。DirectPlay可以同时处理多个线程任务。DirectPlay通过线程池（thread pool）的技术来完成对多线程的管理，你所用的线程是这个池子所提供的。线程池的大小是通过Windows2000的进程处理准则规定的。这方面的知识你可以查看Mircrosoft Developer Network documents或者Win32 的多线程参考部分。
为了正确且可靠的从DirectPlay回调处接收到数据，你最好使用多线程同步技术。同步技术将有助你保持线程安全。

微软的操作系统提供三种方法来保持在多线程中数据的同步。

1 Mutex Objects
2 Semaphore Objects
3 Critical Section Objects

在DirectPlay Voice例子中使用了Critical Section Objects技术来同步数据。如果你希望使用前两种方法，在Microsoft Platform SDK中有查。同步技术的运用需要有较强的能力，SDK废话太多，就是说这个技术很不容易运用。
DirectPlay线程模块已经被最大程度的优化，在执行"send"操作和"indication"消息时(包括接收消息)，没有线程设置开关，也就是不允许多个线程同时执行这两项操作，每次send只有一个线程，其它线程进行等待。（这段话翻译的不好：there are no thread context switches during "send" operations and during "indication" messages, including receive messages.）

DirectPlay Networking Callbacks
DirectPlay用于网络得回调函数是PFNDPNMESSAGEHANDLER类型的。依靠这种类型的网络会话，你可以用IDirectPlay8Peer::Initialize, IDirectPlay8Client::Initialize, 和IDirectPlay8Server::Initialize来注册回调函数。

同步问题
当在回调函数处理过程中，必须使用一个同步对象来保持游戏数据可靠。
为了理解你的游戏数据如何成为不可靠的，可以这样来考虑，在回调响应中，第一个线程将一段数据添入到结构体。如果另外一个线程在第一个线程没有执行完毕之前，进入回调中，并且试图操作那个结构体中的数据（同一个内存块中）。因此，被第一个线程更新的结构被第二个线程重新覆盖，导致了数据的错误。请注意到这只是多线程中一个简单的情况。
在Implementing a DirectPlay Networking Callback Using Critical Section Objects有一个例子，讲述如何在会话中同步数据。

Worker Threads
你可以自己定义一个"Worker Threads"。Worker Threads是另外一个多线程程序，它基于DirectPlay回调函数来处理游戏数据。这种方法的作用是在DirectPlay回调线程中接收数据缓存，。一个新的线程被创建，并且一个消息被发送到你的Worker Threads回调中，来标记处理缓冲数据。

Multithreading Performance Issues and Asynchronous Operations
需要慎重考虑在回调过程中处理信息所花的时间来。如果你有大量的信息在一个回调过程中，并且你使用了数据锁定来同步线程数据，你就会遇到线程堵塞问题。

如果你选择了worker thread和在另外一个回调中进行游戏数据的处理补偿，你就增加了CPU的处理时间。如果你在worker thread中设置了一些非关键性的数据处理过程，数据处理会更加占用CPU时间。

你可以在回调过程中返回DPNSUCCESS_PENDING，创建一个数据缓冲指针，然后使这个指针在worker thread中有效。当worker thread处理完了游戏数据，你就可以调用ReturnBuffer方法，来完成上述步骤。（IDirectPlay8Peer、 IDirectPlay8Client所提供的ReturnBuffer方法）