multithreading - 在 Posix 上旋转的关键部分?

标签 multithreading winapi synchronization posix mutex

Windows API 提供了临界区,其中等待线程将在上下文切换之前旋转有限的次数,但仅限于多处理器系统。这些是使用 InitializeCriticalSectionAndSpinCount 实现的。 (参见 http://msdn.microsoft.com/en-us/library/ms682530.aspx。)当您有一个通常只会被锁定很短时间的关键部分时,这是有效的,因此争用不应立即触发上下文切换。两个相关问题:

  1. 对于高级、跨平台的线程库或 synchronized block 的实现,在触发上下文切换之前进行少量旋转是否是一个好的默认设置?
  2. 什么(如果有的话)与其他操作系统(尤其是 Posix)上的 InitializeCriticalSectionAndSpinCount 等效?

编辑:当然,没有哪种旋转计数对所有情况都是最佳的。我只对使用非零旋转计数是否比不使用一个更好的默认设置感兴趣。

最佳答案

我的观点是,最佳应用程序性能的最佳“自旋计数”过于依赖硬件,以至于不能成为跨平台 API 的重要组成部分,您应该只使用互斥体(在 posix 中,pthread_mutex_init/destroy/lock/trylock) 或自旋锁 (pthread_spin_init/destroy/lock/trylock).理由如下。

旋转计数有什么意义?基本上,如果锁拥有者与试图获取锁的线程同时运行,那么锁拥有者可能会足够快地释放锁,以至于 EnterCriticalSection 调用者可以避免在获取锁时放弃 CPU 控制,从而提高该线程的性能,并避免上下文切换开销。两件事:

1:显然这依赖于锁所有者与尝试获取锁的线程并行运行。这在单个执行核心上是不可能的,这几乎可以肯定是 Microsoft 在此类环境中将计数视为 0 的原因。即使有多个内核,当另一个线程试图获取锁时,锁所有者也很可能没有运行,在这种情况下,最佳自旋计数(对于该尝试)仍然是 0。

2:在同时执行的情况下,最佳自旋计数仍然取决于硬件。不同的处理器将花费不同的时间来执行类似的操作。它们有不同的指令集(我使用最多的 ARM 没有整数除法指令),不同的缓存大小,操作系统在内存中会有不同的页面......减少自旋计数可能需要不同的时间加载-存储体系结构比算术指令可以直接访问内存的体系结构更好。即使在同一个处理器上,同一个任务也会花费不同的时间,这取决于(至少)内存缓存的内容和组织。

如果同时执行的最佳自旋计数是无限的,那么 pthread_spin_* 函数应该可以满足您的需求。如果不是,则使用 pthread_mutex_* 函数。

关于multithreading - 在 Posix 上旋转的关键部分?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1919135/

相关文章:

c# - 花在同步上的线程时间是否太高?

c# - 如何在 C# 中使用低级键盘钩子(Hook)来抑制任务切换键(winkey、alt-tab、alt-esc、ctrl-esc)

windows - TrackPopupMenu "harm"是我的 HMENU 吗?

c++ - 如何防止 "How do you want to open this file"对话框?

java - 为 NavigableMap 编写同步线程安全包装器

java - 具有固定大小线程池的 ExecutorService - 如何阻止添加更多任务,直到池大小有空间

c# - 如何在 C# 中实现我自己的 TaS-Lock?

javascript - AngularJS 加载服务然后调用 Controller 并渲染

python - 在python中监控线程同步

c++ - 接收 MFC 对话框的 PostMessage 消息