Tag: 线程线程同步

可观察对象的同步机制

让我们假设我们必须同步对共享资源的读/写访问。 多个线程将在读取和写入时访问该资源（大多数时间用于读取，有时用于写入）。 让我们假设每次写入总是会触发读操作（对象是可观察的）。 对于这个例子，我会想象一个像这样的类（原谅语法和风格，它仅用于说明目的）： class Container { public ObservableCollection Operands; public ObservableCollection Results; } 我很想将ReadWriterLockSlim用于此目的而且我将它放在Container级别（想象对象不那么简单，一个读/写操作可能涉及多个对象）： public ReadWriterLockSlim Lock; Operand和Result实现对于此示例没有意义。 现在让我们设想一些观察Operands代码，并生成一个放入Results ： void AddNewOperand(Operand operand) { try { _container.Lock.EnterWriteLock(); _container.Operands.Add(operand); } finally { _container.ExitReadLock(); } } 我们的hypotetical观察者会做类似的事情，但是要使用一个新元素，它将使用EnterReadLock()锁定以获取操作数，然后使用EnterWriteLock()来添加结果（让我省略代码）。 这会因为递归而产生exception，但是如果我设置了LockRecursionPolicy.SupportsRecursion那么我只需将代码打开到LockRecursionPolicy.SupportsRecursion （来自MSDN ）： 默认情况下，使用LockRecursionPolicy.NoRecursion标志创建ReaderWriterLockSlim的新实例，并且不允许递归。 建议对所有新开发使用此默认策略，因为递归会引入不必要的复杂性并使您的代码更容易出现死锁 。 为清楚起见，我重复相关部分： 递归[…]使您的代码更容易出现死锁。 如果我对LockRecursionPolicy.SupportsRecursion没有错，如果从同一个线程我问一个，比如读锁定然后别人要求写锁定然后我会有一个死锁然后MSDN说的有意义。 此外，递归也会以可测量的方式降低性能（如果我使用的是ReadWriterLockSlim而不是ReadWriterLock或Monitor ，则不是我想要的）。 问题（S） 最后我的问题是（请注意我不是在寻找关于通用同步机制的讨论，我知道这个生成器/ observable / observer场景有什么问题 ）： 在这种情况下有什么好处？ 为了避免ReadWriterLockSlim支持Monitor […]