8

我的团队正在 C# 5.0 中使用 async/await 开发一个多线程应用程序。在实现线程同步的过程中，经过多次迭代，我们提出了一个（可能是新颖的？）带有内部锁的新 SynchronizationContext 实现：

  1. 调用 Post 时：
    • 如果可以获取锁，则立即执行委托
    • 如果无法获取锁，则委托排队
  2. 调用发送时：
    • 如果可以获取锁，则执行委托
    • 如果无法获取锁，则线程被阻塞

在所有情况下，在执行委托之前，上下文将自己设置为当前上下文，并在委托返回时恢复原始上下文。

这是一个不寻常的模式，因为我们显然不是第一个编写这样一个应用程序的人，我想知道：

  1. 模式真的安全吗？
  2. 有没有更好的方法来实现线程同步？

这是 SerializingSynchronizationContext 的源代码和GitHub 上的演示。

以下是它的使用方法：

  • 每个需要保护的类都创建自己的上下文实例，如互斥锁。

  • 上下文是可等待的，因此可以使用以下语句。

    await myContext;

    这只会导致方法的其余部分在上下文的保护下运行。

  • 类的所有方法和属性都使用这种模式来保护数据。在等待之间，一次只能在上下文上运行一个线程，因此状态将保持一致。当到达等待时，允许下一个调度线程在上下文上运行。
  • 如果需要即使使用等待的表达式也可以保持原子性，自定义 SynchronizationContext 可以与 AsyncLock 结合使用。
  • 类的同步方法也可以使用自定义上下文进行保护。
4

2 回答 2

4

拥有一次从不运行多个操作的同步上下文当然不是新奇的，而且一点也不坏。 在这里，您可以看到 Stephen Toub 描述如何在两年前制作一个。（在这种情况下，它只是用作创建消息泵的工具，实际上听起来可能正是您想要的，但即使不是，您也可以将同步上下文从解决方案中拉出并单独使用。）

当然，拥有一个单线程同步上下文在概念上是完美的。所有代表 UI 状态的同步上下文都是这样的。winforms、WPF、winphone 等同步上下文都确保一次只运行来自该上下文的单个操作。

令人担忧的一点是：

在所有情况下，在执行委托之前，上下文将自己设置为当前上下文，并在委托返回时恢复原始上下文。

我会说上下文本身不应该这样做。如果调用者希望这个同步上下文成为当前上下文，他们可以设置它。如果他们想将其用于当前上下文以外的其他内容，您应该允许他们这样做。有时您想使用同步上下文而不将其设置为当前上下文来同步对某个资源的访问；在这种情况下，只有专门访问该资源的操作才需要使用此上下文。

于 2014-01-08T15:36:10.520 回答
2

关于锁的使用。这个问题更适合Code Review，但乍一看我不认为你SerializingSynchronizationContext.Post做得很好。尝试在一个紧密的循环中调用它。由于Task.Run((Action)ProcessQueue)，您很快就会遇到越来越多的ThreadPool线程在lock (_lock)等待内部获取它时被阻塞ProcessQueue()。

[编辑]为了解决评论，这是您当前的实现：

public override void Post(SendOrPostCallback d, object state)
{
    _queue.Enqueue(new CallbackInfo(d, state));

    bool lockTaken = false;
    try
    {
        Monitor.TryEnter(_lock, ref lockTaken);

        if (lockTaken)
        {
            ProcessQueue();
        }
        else
        {
            Task.Run((Action)ProcessQueue);
        }
    }
    finally
    {
        if (lockTaken)
        {
            Monitor.Exit(_lock);
        }
    }
}

// ...

private void ProcessQueue()
{
    if (!_queue.IsEmpty)
    {
        lock (_lock)
        {
            var outer = SynchronizationContext.Current;
            try
            {
                SynchronizationContext.SetSynchronizationContext(this);

                CallbackInfo callback;
                while (_queue.TryDequeue(out callback))
                {
                    try
                    {
                        callback.D(callback.State);
                    }
                    catch (Exception e)
                    {
                        Console.WriteLine("Exception in posted callback on {0}: {1}", 
                            GetType().FullName, e);                 
                    }
                }
            }
            finally
            {
                SynchronizationContext.SetSynchronizationContext(outer);
            }
        }
    }
}

在中，为什么在已经在另一个池线程上循环循环并调度回调的情况下Post，为什么将回调加入队列_queue.Enqueue，然后从池中占用一个新线程？在这种情况下，对我来说似乎浪费了一个池线程。Task.Run((Action)ProcessQueue)ProcessQueue() _queueTask.Run

于 2014-01-08T22:11:27.183 回答