我有两个线程引用同一个变量——UI 线程和一个计时器线程。因此，我已经在两个线程的 lock 语句中包装了对它的访问。定时器线程的访问具有优先级——如果它正在使用变量并且 UI 线程也想要访问，我希望 UI 线程的操作完成，但只有在定时器线程的操作完成之后。
但是，计时器线程可能委托给 UI 线程，因此 UI 线程需要有空闲来处理它。为了适应这种情况，我让 UI 线程启动第三个线程来处理其操作，以便它（第三个线程）可以等待计时器操作完成并且 UI 线程可以使用。锁定发生在第三个线程中。
我应该为这种同步使用什么正确的模式？
【问题讨论】：
标签： c# synchronization multithreading
一般建议是，关键部分中发生的任何事情都应尽可能简单。特别是你应该避免嵌套锁。嵌套锁可能是死锁的根源。
当应用于您在“计时器”线程中所做的事情时，您可能应该将关键部分与处理分开。定时器线程中的 IOW 只是从公共变量中检索数据，然后执行其余的处理，包括与锁外的 UI 线程的交互。
添加第三个线程不会让您的生活更轻松
【讨论】：
经验法则是尽可能最短使用最轻锁。
这里有一篇不错的文章：http://www.moserware.com/2008/09/how-do-locks-lock.html
【讨论】：
要遵循的一般规则是尽量减少持有锁的时间，并且不要调用不属于你的代码（例如事件、虚拟方法或 UI 线程） ) 同时持有锁。
因此，计时器不应在持有锁时回调到 UI。如果它需要对锁定下的数据进行事务访问（读取、调用 UI、写入），那么它可能应该被设计为回滚和/或重试。
【讨论】：
就像 mfeingold 所说，尽可能避免它。在无法避免的地方，请注意以相同的顺序锁定两个线程！我的意思是，如果你有三个锁 A、B 和 C，如果你有以下锁模式
那么可能会出现死锁...
嵌套锁通常会降低性能，因为您必须锁定外部锁，即使您有时不需要确保在从另一个线程调用该方法的情况下行为正确。
【讨论】：
你为什么要这样做？这听起来很复杂且容易出错。
委托给 UI 线程的计时器线程有什么用？
这可能是必要的，但我的直接反应是，您可能需要退后一步，考虑您的设计是否不必要地迫使您陷入复杂的同步问题。
【讨论】：