构建更好的线程安全集合

  • Jonathan Allen
  • 赵劼

2009 年 2 月 26 日

话题:.NET语言 & 开发架构

大部分线程安全的集合都有一些基础性的缺陷:虽然每个操作都是线程安全的,但是多个操作无法组合起来使用。这意味着一些基本的执行顺序,例如在弹出顶部元素之前检查栈内元素数量会出现潜在的危险。尽管已经有一些 API 设法将某些操作绑定起来(例如.NET 4 的 Coordination Data Structures),但是它们往往会引入丑陋的方法(如 TryDequeue)。 

.NET 1 里的集合尝试了另一种方式,它们会对外暴露一个 SyncRoot 属性,而不是在内部进行锁定。虽然 SyncRoot 仍然是同步对象的默认机制,但是.NET 2 已经抛弃了 SyncRoot/Wrapper 设计模式

那么该如何创建一个可用的组合式 API 呢?Jared Parson 认为集合不应该直接暴露出线程安全的 API,所有的方法都应该属于一个临时的对象,而这个对象只有在您锁定集合的时候才被创建出来。这个临时对象是集合的“钥匙”,只有钥匙的持有者才能获取集合内容。 

以下示例为Jared Parsons 的线程安全队列: 

static void Example1(ThreadSafeQueue queue) {

using (var locked = queue.Lock()) {

if (locked.Count > 0) {

var first = locked.Dequeue();

}

}

}

名为 locked 的对象本身不是线程安全的,但是开发人员只有在 using 代码块中才能正确执行操作。在遵守了这一简单规则之后,开发块里的所有代码就是线程安全的。Jared 解释道: 

与大部分线程安全的设计一样,这些代码还是有被误用的可能:

  1. 在 ILockedQueue销毁之后却继续使用它。这种做法应该被禁止,用户现有的知识一般足以避免这个问题。此外一些静态检查工具,例如 FxCop,会把这种做法识别为一个错误。我们也可以使用一种更严厉的做法来阻止此类情况出现:添加一个 disposed 标记,并在每个方法中进行检查。
  2. 如果用户在跨越多个 Lock 语句的情况下保留某个值(例如 Count),那么可能会对集合的状况出现错误的判断和假设。

     
  3. 如果用户没有正确销毁 ILockedQueue,那么这个对象会被永久锁定。幸运的是,对于实现了 IDisposable 的对象,FxCop 同样会将这种做法识别为一个错误——尽管这不是一个万分稳妥的机制。
  4. 无法确定用户是否会长期持有 ILockedQueue对象。虽然 IDisposable 一般包含着“短期”的意味,但是这并不能做出完美的保证。
  5. ILockedQueue并不是线程安全的。虽然一般情况下用户不会把 IDisposable 对象交给多个线程使用,但这也是必须考虑到的情况之一。

查看英文原文:Building a Better Thread-safe Collection

 

.NET语言 & 开发架构