使用async/await时,使用自定义SynchronizationContext序列化执行

Question

我的团队正在使用C#5.0中的async/await开发一个多线程应用程序.在实现线程同步的过程中,经过几次迭代,我们想出了一个(可能是新颖的？)新的SynchronizationContext实现,它有一个内部锁:

1. 在致电Post时:
   • 如果可以进行锁定,则立即执行委托
   • 如果无法获取锁定,则委托将排队
2. 致电发送时:
   • 如果可以执行锁定,则执行委托
   • 如果无法进行锁定,则线程被阻止

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

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

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

这是SerializingSynchronizationContext的源代码和GitHub上的一个演示.

以下是它的使用方法:

• 每个需要保护的类都会像互斥锁一样创建自己的上下文实例.

• 上下文是可以接受的,因此可以使用以下语句.

  await myContext;

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

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

Answer 1

拥有一个永远不会同时运行多个操作的同步上下文当然不是什么新鲜事，而且一点也不坏。 在这里你可以看到斯蒂芬·托布（Stephen Toub）在两年前描述了如何制作一个。（在本例中，它只是用作创建消息泵的工具，这实际上听起来可能正是您想要的，但即使不是，您也可以将同步上下文从解决方案中提取出来并单独使用。）

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

令人担忧的一点是：

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

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