Question

我不确定在我计划做的事情中使用异步是否是最有效的方式，所以我决定问你们你对它的看法。

Backstory ：我正在开发一款MMORPG游戏的服务器模拟软件，该游戏中有NPC存在于其中。您（客户端）可以通过对话框与NPC交互。对话框向播放器显示文本以及选项（某些对话框为是/否对话框，接受/拒绝等）。

我决定使用C＃作为NPC的脚本界面＆＃39;脚本。当服务器启动时，它会为每个NPC编译并保存已编译脚本的程序集，当玩家与其中一个NPC交谈时，它会执行所需的脚本。

现在，让我们说用户必须向服务器提供输入。首先，我们显示一个带有是/否问题的窗口。

客户端显示以下内容：

＆＃34;您想收到Apple吗？＆＃34; 是/否

脚本本身在发送对话框后停止，直到它使用异步从客户端收到响应。发送对话框的方法返回布尔值的任务（对于是，为true，对于否，为false），并且是异步的。响应是一种布尔值的TaskCompletionSource。所以，方法是这样的：

TaskCompletionSource<bool> _response; 

public async Task<bool> SendDialog()
{
     _response = new TaskCompletionSource<bool>();
     [... the packet that shows the dialog]
     return await _response.Task;
}

因此，正如您所看到的那样，它一直等到响应设置完毕然后才返回响应。

服务器收到响应数据包后，会根据输入设置响应。

_response.SetResult(...);

然后脚本继续（因为输入已经给出）。

现在，我想问你们这对于高端服务器有多高效，是否能以某种方式进行改进？或者是否有其他方法可以暂停脚本直到输入？

Answer 1

这种方法具有很好的权重和效率，因为它专门针对这些高级任务而设计：GUI交互，高级业务逻辑，并行任务，任务链等。

虽然在低级应用程序中使用时效率不高，例如内存占用少，系统调用，高级任务等的I / O操作。

顺便说一句，看看你的例子，我可以看到一个不必要的等待。你可以改为简化：

TaskCompletionSource<bool> _response; 

public Task<bool> SendDialog()
{
     _response = new TaskCompletionSource<bool>();
     // [... the packet that shows the dialog]
     return _response.Task;
}

根据定义，async方法只是编译器生成的任务。由于您在此处使用TaskCompletionSource，因此您已经手动生成任务。没有必要将它包装在另一个（编译器生成的）任务中。

C＃ - 为高端服务器使用async

1 个答案: