实时应用程序中的同步与异步更新
我正在寻找更新一个能够同步或异步更新的应用程序。对于应用程序的实时性（目前方法的同步执行频率范围为 1-60Hz），您认为由于用户输入而异步更新有什么优势吗？或者我应该等到下一个同步周期才能合并更改？
到目前为止我的想法：
我认为引入异步更新的当前优点是，如果更新 1Hz 方法中的成员，则 60Hz 方法可能会使用旧值执行 50 次以上。我知道这对于用户来说仍然是相对较短的时间（<1 秒），但对我来说，持续计算 50 次以上的错误值的原则似乎很糟糕。
我认为保持同步的当前优势是代码执行流程的可读性。
有没有我没有想到的后果？
I am looking to update an application in which I have the ability to update synchronously or asynchronously. For the real-time nature of the app, which currently ranges from a synchronous execution of methods ranging in frequencies from 1-60Hz, do you see any advantages into asynchronously updating due to user input? Or should I wait until the next synchronous cycle to incorporate the change?
My thoughts so far:
The current advantage that I see with introducing an asynchronous update is that if a member in a 1Hz method is updated, the 60Hz method may execute 50+ times with the old value. I know this is still a relatively short amount of time to a user ( < 1 second), but to me the principal of continuing calcs with bad values for 50+ reps seems bad.
The current advantage that I see with keeping it synchronous is the ease of readability for the flow of code execution.
Are there any repercussions I am not thinking of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果不了解您的应用程序，就很难说。一般来说，我认为最好是在可能的情况下对实时应用程序保持同步，因为它可以更容易地推理及时性（通常是最难推理的事情）。如果您可以合理地使某些东西周期性化，那么它是定期的，感谢你的幸运星。
转向部分同步或异步模型确实有一些优点。就像你说的，继续对陈旧数据进行操作可能会让人感觉不太美观。但请考虑：这是一个实时应用程序。想必您有一个要求，规定输入到 60Hz 任务的数据的更新延迟必须是多少。就像在任何通用计算性能设置中一样，不要为了做得更好而做额外的工作，除非它很容易；执行起来更加清晰；或者有必要实现正确性。
综上所述，没有硬性规定。确保你的理由被写下来并反映在你的设计中。
It's a little hard to say without more of a sense of your application. In general, I'd say it's preferable to stay synchronous for a real-time application where possible, just because it makes it easier to reason about timeliness (often the hardest thing to reason about.) If you can reasonably make something periodic, make it periodic and thank your lucky stars.
Moving to a partially synchronous or async model does have some advantages. Like you say, it might feel less than aesthetic to continue operating on stale data. But consider: this is a real-time application. Presumably you have a requirement that states what the update latency for data input to your 60Hz task must be. Like in any general purpose computing performance setting, don't go to extra work to do better than that unless it's easy; it's clearer in the implementation; or it becomes necessary to achieve correctness.
So, all that said, there are no hard and fast rules. Make sure your rationale is both written down and reflected in your design.