【发布时间】：2013-11-17 21:09:10
【问题描述】：
为什么线程数大于逻辑cpu数时mcs锁的吞吐量很差。 会不会是因为 cpu 上的位置争用增加导致很多线程被抢占？
【问题讨论】：
标签： multithreading computer-architecture microprocessors
【发布时间】：2013-11-17 21:09:10
【问题描述】：
对此我不是 100%，但 Microsoft 库给出了 Sleep() 函数的定义：
经过休眠间隔后，线程准备好运行。如果您指定 0 > 毫秒，线程将放弃其时间片的剩余部分，但保持 > 就绪。请注意，不保证就绪线程会立即运行。因此，>线程可能要等到休眠间隔过后的某个时间才会运行。
根据我的经验，如果我使用 MCS 锁来更新数据结构，并且我运行它的线程数是 16，那么从 8 的下降（不包括从 1 到 2 个线程的大量下降）到 16 个线程（假设您只是将线程数增加一倍）非常大。吞吐量在一个线程之后下降到大约三分之一，然后随着正在使用的线程数量接近 CPU 数量而缓慢下降。显然，如果您使用锁，则尝试获取锁的线程越多，您将有更多的缓存缓存一致性工作供 CPU 执行。
如果您使用任何原子指令（再次假设您是），您添加的线程越多，这将变得越慢。
“我认为问题不在于原子操作本身会花费更长的时间；真正的问题可能是原子操作可能会阻塞其他处理器上的总线操作（即使它们执行非原子操作）。”
这是从 stackoverflow 的另一个成员那里获得的，关于类似的问题。再加上线程可能会或可能不会休眠，即使使用Sleep()，并且可能会或可能不会立即唤醒，这可能会导致吞吐量的严重损失。您还需要处理增加的公交车流量......
【讨论】：