我正在使用标准的x86六核SMP机器，时钟频率为3.6GHz，使用纯C代码。
我有一个线程生产者/消费者方案，其中我的“生产者”线程以大约1,000,000行/秒的速度从文件中读取数据，并将读取的数据交给两个或四个“消费者”线程来完成一些工作然后将其粘贴到数据库中。他们正在消费时，正忙于阅读下一行。
因此，生产者和消费者都必须具有某种同步方式，这些方式必须在亚微秒的频率下工作，为此我使用了“繁忙的旋转等待”循环，因为我能找到的所有常规同步机制都太慢了。用伪代码术语：
生产者线程
While(something in file)
{
read a line
populate 1/2 of data double buffer
wait for consumers to idle
set some key data
set memory fence
swap buffers
}
以及消费者线程也是如此
while(not told to die)
{
wait for key data change event
consume data
}
在两边都编码“ wait”循环：
while(waiting)
{
_mm_pause(); /* Intel say this is a good hint to processor that this is a spin wait */
if(#iterations > 1000) yield_thread(); /* Sleep(0) on Windows, pthread_yield() on Linux */
}
所有这些都可以，并且与同等的串行代码相比，我得到了相当不错的提速，但是我的分析器（Intel的VTune Amplifier）表明，我在繁忙的等待循环中花费了大量的时间，并且从“旋转”到“完成有用的工作”令人沮丧。考虑到探查器将其反馈集中在最繁忙的部分上的方式，这也意味着不报告有用的工作代码行，因为（相对而言）它们的总cpu百分比下降到了噪声水平...或至少那是探查者所说的。他们一定在做something，否则我看不到任何提速！
我可以并且可以做一些时间事情，但是很难区分生产者线程中磁盘延迟所带来的延迟和线程同步所花费的延迟。
因此，有更好的方法来衡量实际情况吗？我的意思是这些线程真的需要花费多少时间互相等待？在亚微秒分辨率下，准确地测量时间确实很困难，探查器似乎并没有给我太多帮助，并且我正在努力优化该方案。或者也许我的自旋等待方案是垃圾，但是我似乎找不到亚微秒同步的更好解决方案。
任何提示都将非常受欢迎：-）
我正在使用标准的x86六核SMP机器，时钟速度为3.6GHz，纯C代码。我有一个线程化的生产者/消费者方案，其中“生产者”线程正在从文件中读取大约1,000，...