c - 更好地锁定共享资源，或者有一个线程来完成请求？

Question

我有一个共享内存池，许多不同的线程可以从中请求分配。从中请求分配将在每个线程中发生很多次，但是线程数量可能很小，通常只有 1 个线程在运行。我不确定以下哪种处理方法更好。

最终我可能需要同时实现两者，看看哪个会产生更有利的结果……我也担心此时考虑 #2 可能是过早的优化，因为我实际上没有使用此共享资源的代码写了。但这个问题实在是太有趣了，以至于它继续分散我对其他工作的注意力。

1) 创建一个互斥锁并让一个线程在获取分配之前尝试锁定它，然后解锁它。

2) 让每个线程注册一个请求槽，当它需要分配时将请求放入槽中，然后阻塞(while (result == NULL) { usleep() }) 等待请求槽有一个结果。单个线程不断迭代请求槽，进行分配并将它们分配给请求槽中的结果。

第 1 种方法是简单的解决方案，但如果时机合适，单个线程可能会占用锁。第二个更复杂，但在从资源中提取时确保线程之间的公平性。然而，它仍然会阻塞请求线程，如果有很多线程，迭代可能会在不进行任何实际分配的情况下消耗循环，直到它找到要满足的请求。

注意:Linux 上的 C 使用 pthreads

Answer 1

解决方案 2 是假的。这是一个丑陋的 hack，它不能确保内存同步。

我会说采用解决方案 1，但我有点怀疑您一开始提到的“内存池”这一事实。您只是在尝试分配内存，还是您正在管理其他一些资源(例如，某些特殊类型内存中的插槽、内存映射文件、视频内存中的纹理等)？

如果您只是分配内存，那么担心过早优化是完全正确的。整个问题是过早的优化，系统 malloc 会和你的内存池一样好或更好。 (或者，如果您的代码将在少数具有病态损坏的 malloc 的系统之一上运行，例如一些视频游戏控制台，只需在那些已知损坏的系统上放置替换.)

如果您确实有需要管理的特殊资源，请从解决方案 1 开始，看看它是如何工作的。如果您遇到问题，您可能会发现可以使用条件变量来改进它，资源管理器会在可以分配插槽时通知您，但我真的怀疑这是否有必要。