答案:应该对数据结构使用全局锁
使数据线程安全的最简单方法是把它套上一把大锁。为简单起见,所有的东西都用同一把锁。这种方易做图有一个问题:序列化。为了得到锁,每一个要处理数据的线程都必须排队等候。如果线程被一把锁阻塞,它没有在做任何有用的事。当服务器的负载较轻时,这个问题并不常见,因为一次可能只有一个线程需要锁。在负载很重的情况下,对锁的激烈争夺可能就会成为一个大问题。
设想在多车道高速公路上发生了一个意外事故,这条高速公路上的所有车辆都被转向一条狭窄的道路。如果车辆很少,这一转换对交通流的速率的影响可以忽略。如果车辆很多,当车辆慢慢并入那条单通道时,交通阻塞会延伸几英里。
有几种技术能够减少锁竞争。
· 不要过分保护,也就是说,不是非常必要不要锁住数据。只有需要时才去持有锁,而且时间不要过长。不要在大段代码周围或频繁执行的代码中没必要地使用锁,这一点很重要。
· 对数据进行分割,使它能够用一套独立的锁保护。例如,一个符号表可以按标识符的第一个字母分割,这样在修改名字以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次会更好。性能很差的原因是竞争:锁竞争,总线竞争,和/或缓存列竞争。处理器都在是争夺共享资源的所有权,而不是做更多的工作。
如果你一定要编写多线程应用程序的话,你应该在多处理器盒上对你的应用程序进行强度测试和性能测试。单处理器系统通过时间分片地执行线程而提供一个并发性的假象。多处理器盒具有真正的并发性,竞争环境和竞争更容易发生。
应该始终使用模块化调用;他们很有趣。
利用同步模块化调用来执行I/O操作对大多数桌面应用程序来说是合适的。但是,他们不是使用服务器上的CPU(s)的好方法。I/O操作要花费上百万个时钟周期来完成,这些时钟周期本来可以被更好地利用。利用异步I/O你能得到显著提高的用户请求率和I/O通量,不过增加了额外的复杂性。
如果你有需要花费很长时间的模块化调用或I/O操作,你应该考调拨多少资源给他们。你想使用所有的线程还是有个限制?一般地,使用有限的几个线程要好些。构建一个小的线程池和队列,利用队列来安排线程的工作完成模块化调用。这样,其他线程就可以拾取和处理你的非模块化的请求。
上一个:扼杀服务器性能的10条戒律(转,接前文)
下一个:优化ASP程序