具有异步服务初始化的竞争条件

Question

我正在使用专有框架（基本上是 Caliburn Micro 和 Castle Windsor 的混合体）在 C# WPF 中工作，并且我有两个具有竞争条件的单例模块：

DeviceService - 管理与发送数据的物理设备的连接的服务。该服务是“可启动的”，因此会自动构造和初始化异步。

ConnectionIndicatorViewModel - 一个客户端 ViewModel，主要关注与用户交流由DeviceService 管理的连接状态。主要根据DeviceService 触发的事件更改状态。

我的问题在于应用程序启动。在 ViewModel 的构造函数中，我将默认状态设置为“Pending”，因为我假设 Service 尚未完成初始化。然后 ViewModel 简单地处理服务触发的“初始化”事件。在这个处理程序中，我通过 Service 上的属性评估实际连接状态并更新 ViewModel。

现在，所有这些都可以正常工作，因为竞争条件极不可能出现。但是，如果服务在构造 ViewModel 之前完成其初始化，它永远不会处理“初始化" 事件，并且只会保持其“待处理”状态。

我考虑过更改 Service 接口以返回属性的可等待类型，以便任何尝试访问属性的模块都必须等待初始化完成，但我不确定这是不是最好的方法。我也担心让部分客户端启动服务，因为如果有多个模块使用它，谁应该初始化它？

是否有一些我缺少的处理这种异步初始化的传统方法？

Answer 1

您提到使用事件在服务和 ViewModel 之间进行通信，您可以使用响应式扩展 (Rx) 而不是使用事件，这可以消除您上面描述的竞争条件。

简单地说，这会将服务从拉模型转变为推模型，它将通过流推出数据\事件，并允许您在流上编写 LINQ 查询。如果您不熟悉 Rx，这里有很多很好的信息。

在这种使用 Rx 的场景中，我会让服务公开一个属性 IObservable<T>;，其中 T 是你的类型（我猜是某种状态枚举），这个属性的支持字段是重要的部分，这将是大小为 1 的 ReplaySubject<T>。这意味着任何时候有人“订阅”该属性，他们将收到发布给主题的最后一个值。因此，这意味着发布和订阅流之间不存在竞争条件。

这在代码中可能更容易理解：

public enum State
{
    Initializing,
    Initialized,
}

public interface IMyService
{
    IObservable<State> Status { get; }
}

public class MyService : IMyService
{
    private ReplaySubject<State> _state;

    public MyService()
    {
        _state = new ReplaySubject<State>(1);

        _state.OnNext(State.Initializing);

        // Do initialisation stuff

        _state.OnNext(State.Initialized);

    }
    public IObservable<State> Status { get { return _state;  } }
}

该示例仅说明在当前线程上初始化服务（即同步），这意味着它会阻塞调用线程，如果这是基于 XAML 的应用程序，我猜这将是 Dispatcher 线程。

如果您需要异步完成初始化，您可以考虑使用Observable.Create<T> 或Observable.Start<T> 在后台线程上启动工作，以免阻塞调度程序 (UI) 线程。

要使用此服务，您需要执行以下操作：ViewModel：

public class MyViewModel
{
    private State _state;

    public MyViewModel(IMyService myService)
    {
        myService.Status.ObserveOn(DispatcherScheduler.Current)
            .Subscribe(x =>
                        {
                            _state = x;
                        });
    }

    public bool IsReady { get { return _state == State.Initialized; } }
}

现在 Service 和 ViewModel 之间没有竞争条件。

关于 Reactive Extensions 可以学到很多东西，但它是在实现 MVVM 应用程序时处理异步调用的好方法。