更好地锁定共享资源，或有一个线程来满足请求？

Question

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

最终，我可能需要实现两者，看看哪一个会产生更有利的结果......我还担心，即使考虑＃2可能是过早优化，因为我实际上没有使用此共享的代码资源尚未写入。但是这个问题非常有趣，它会让我从其他工作中分心。

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

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

数字1是简单的解决方案，但如果时机正确，单个线程可能会锁定锁定。第二个更复杂，但确保从资源拉出时线程之间的公平性。但是它仍然会阻塞请求的线程，并且如果有多个线程，则迭代可能会在不发生任何实际分配的情况下刻录循环，直到找到请求来完成。

注意：在Linux上使用pthreads的C

Answer 1

解决方案2是虚假的。这是一个丑陋的黑客，并不能确保内存同步。

我会说解决方案1，但我有点怀疑你提到“内存池”开始的事实。你只是试图分配内存，还是有一些其他的资源（例如某些特殊类型的内存插槽，内存映射文件，视频内存中的纹理等）？

如果你只是分配内存，那么你完全有理由担心过早的优化。整个问题是不成熟的优化，并且系统malloc将会比你的内存池做得更好或更好。 （或者，如果你的代码将在一个病理破malloc像一些视频游戏机的少数系统之一运行，只是下降的替代，只有对那些已知的破碎系统）

如果你真的有您需要管理的特殊资源，从解决方案1开始，看看它是如何工作的。如果你有问题，你可能会发现你可以用一个条件变量来改善它，当资源管理器通知你什么时候可以分配一个槽，但是我真的怀疑这是必要的。