应该对数据结构使用全局锁
使数据线程安全的最简单方法是把它套上一把大锁。为简单起见,所有的东西都用同一把锁。这种方法会有一个问题:序列化。为了得到锁,每一个要处理数据的线程都必须排队等候。如果线程被一把锁阻塞,它没有在做任何有用的事。当服务器的负载较轻时,这个问题并不常见,因为一次可能只有一个线程需要锁。在负载很重的情况下,对锁的激烈争夺可能就会成为一个大问题。
设想在多车道高速公路上发生了一个意外事故,这条高速公路上的所有车辆都被转向一条狭窄的道路。如果车辆很少,这一转换对交通流的速率的影响可以忽略。如果车辆很多,当车辆慢慢并入那条单通道时,交通阻塞会延伸几英里。
有几种技术能够减少锁竞争。
・ 不要过分保护,也就是说,不是非常必要不要锁住数据。只有需要时才去持有锁,而且时间不要过长。不要在大段代码周围或频繁执行的代码中没必要地使用锁,这一点很重要。
・ 对数据进行分割,使它能够用一套独立的锁保护。例如,一个符号表可以按标识符的第一个字母分割,这样在修改名字以Q开头的符号的值时,就不会去读名字以H开头的符号的值。
・ 使用APIs的Interlocked 系列(InterlockedIncrement,InterlockedCompareExchangePointer等)自动修改数据而不需要锁。
・ 当数据不是经常被修改时可以使用多读者/单作者(multi-reader/single-writer)锁。你将获得更好的并发性,尽管锁操作的代价将更高并且你可能会冒饿死作者的危险。
・ 在关键部分使用循环计数器。参见Windows NT 4.0 service pack 3中的SetCriticalSectionSpinCount API。
・ 如果你不能得到锁,使用TryEnterCriticalSection并做一些其他的有用的工作。
高竞争导致serialization,serialization导致降低CPU的利用率,这促使用户加入更多的线程,结果事情变得更糟。
不必注意多处理器机器
你的代码在多处理器系统上比在单处理器系统上运行得还要糟,这可能是件令人恶心的事。一个很自然的想法是,在一个N维系统上运行N次会更好。性能很差的原因是竞争:锁竞争,总线竞争,和/或缓存列竞争。处理器都在是争夺共享资源的所有权,而不是做更多的工作。
如果你一定要编写多线程应用程序的话,你应该在多处理器盒上对你的应用程序进行强度测试和性能测试。单处理器系统通过时间分片地执行线程而提供一个并发性的假象。多处理器盒具有真正的并发性,竞争环境和竞争更容易发生。