【问题标题】:How to decouple an ObservableCollection?如何解耦 ObservableCollection?
【发布时间】:2023-03-04 12:08:01
【问题描述】:

我开发了一个作为 DLL 的数据采集子系统,它使用自己的线程捕获数据并使用 ObservableCollections 发布数据。我面临几个问题,因为事件的消费者在收到 ObservableCollection 事件时会执行昂贵的操作,这使得我的引擎捕获数据的速度比预期的要慢。

我计划在不同的线程中发送事件以避免这个问题,但我有几个问题:

public class ObservableCollection2
{
    public void Add()
    {
        _internalObservableCollection.Add();
        new Thread() { => Raise the event }
    }
}
  1. 这是标准解决方案已经解决的问题吗?看起来 像线程争用应该是比较普遍的事情。
  2. 使用线程不会严重降低 应用?
  3. 使用 ThreadPool 不会使用所有可用的 线程在子系统中从 100 发送到 200 是正常的 每秒通知?

感谢您的意见。

【问题讨论】:

    标签: .net multithreading thread-safety threadpool observablecollection


    【解决方案1】:

    对于这种情况可以做些什么,有几个想法。

    1. 客户端不能在事件处理程序中执行繁重的代码——毕竟,他们知道他们正在阻塞处理。因此客户端必须记住集合已更改,并将处理卸载到私有线程中。
    2. 为每个事件使用一个新线程并不是最好的解决方案。如果您仍然这样做,那么线程池线程可能是一个更好的主意。
    3. 如果有关更改的消息经常出现,也许您想限制通知,并以更大的包发送它们?我不知道开箱即用的解决方案,但也许 Rx 扩展会有所帮助。
    4. ObservableCollection 是一个相当沉重的课程。我个人只在视图模型中使用它来从视图绑定,并且在模型中我求助于一个自制的包含内部集合的类,并在需要时发送所需的事件。这样我可以更好地控制发生的事情。

    【讨论】:

    • 感谢您的想法。关于您的想法: 1)我无法管理客户对他们的处理程序所做的事情。 2)我认为 ThreadPool 只能服务几个线程。 3)我会看看这个想法,谢谢。 4) 我也喜欢这种方法,再次感谢。
    • @SoMoS: 1) 好吧,如果您定义处理程序必须快速,并且客户不遵守 - 他们自己有罪,而不是您; 2) 是的,但是如果有很多调用,线程的数量会动态增加,无论如何,如果旧的事件没有完成,你不应该开始下一个事件——所以你只会使用一个线程。也许你可以有一个内部线程并在其中运行一个任务队列?
    • 弗拉德:关于2,你为什么认为我不应该开始下一个活动,因为旧的活动还没有完成?
    • 我的意思是,如果我这样做,除非我运行任务队列,否则我将不得不锁定。如果我可以避免使用任务队列,我宁愿不使用它,因为我正在运行几个可观察的集合,这将是一个不错的开销。我正在获取对象集合,其中包含对象集合...
    • @SoMoS:因为客户端通常不希望他们的函数被“递归”调用,即不希望同一事件处理程序的两个实例同时运行。所以他们通常不关心在事件处理程序运行期间保持内部结构的一致状态。
    猜你喜欢
    • 2015-08-25
    • 2016-09-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-05-10
    • 2021-11-02
    相关资源
    最近更新 更多