【问题标题】:Pseudo real time threading伪实时线程
【发布时间】:2011-05-12 05:44:14
【问题描述】:

所以我构建了一个带有物理引擎和显示器的小应用程序。显示器附加到处理物理引擎的控制器(实际上是处理控制器的视图模型,但细节)。

目前,控制器是一个委托,由 begin-invoke 激活并由取消令牌停用,然后由 endinvoke 收割。在 lambda 内部画笔 PropertyChanged(挂钩到 INotifyPropertyChanged),它使 UI 保持最新。

据我了解,BeginInvoke 方法激活的是一个任务而不是另一个线程(在我的计算机上确实激活了另一个线程,但这并不能保证我已经完成的阅读,这取决于线程池它想要的方式完成任务),从我所做的所有测试来看,这都很好。直到 CancellationToken 被杀死,lambda 才会完成。它有一个睡眠和一个更新(所以它有点模拟实时物理引擎......它很粗糙,但我不需要实时的真正精确度,只需要感受一下)

我的问题是,这是否适用于其他计算机,或者我应该切换到我启动和取消的显式线程?我正在考虑的场景是在一个 1 核处理器上,第二个任务是否有可能会大大减少处理器时间,从而使我可以接受的不准确模型变成不可接受的不准确的东西(即在切换之前等待毫秒而不是微秒?)。还是他们有一些我没有想到的更好的方法?

【问题讨论】:

  • 这是 .NET 吗?如果是,您可能希望将您的问题与您使用的编程语言一起标记。

标签: multithreading user-interface asynchronous real-time threadpool


【解决方案1】:

根据我的经验,以您描述的方式使用线程池几乎可以保证在大多数计算机上获得合理的最佳性能,而您不必费心找出如何分配线程。

线程与内核不同;您仍然会在单核机器上获得多个线程,并且这些线程将各自承担处理负载的一部分。你不会得到你描述的“死锁”情况,除非你对线程做了一些不寻常的事情,比如给其中一个实时优先级。

也就是说,微秒对于线程之间的上下文切换来说并不是很多时间,所以 YMMV。您必须尝试一下,看看效果如何;可能需要进行一些调整。

【讨论】:

    猜你喜欢
    • 2018-09-19
    • 2017-03-27
    • 2019-04-09
    • 1970-01-01
    • 1970-01-01
    • 2015-08-03
    • 1970-01-01
    • 1970-01-01
    • 2019-01-26
    相关资源
    最近更新 更多