Question

我需要在Win7 x64上实现与此功能相同的功能。

我最初使用SwitchToThread()但这不起作用，因为它会在极端条件下导致死锁。我能找到的唯一替代方案是Sleep()但这很可能是一个性能杀手，因为它只能在毫秒级分辨率下工作，我仍然不确定它与LockSupport.parkNanos()做同样的事情。

我发现Java有能力安排（如果发生这种情况）线程在纳秒间隔可疑，所以我实现了我只能假设他们做...旋转。但是我不确定这是否解决了问题，它可能只是推迟了不可避免的事情，因为Java函数似乎需要JVM的干预才能工作。没有parkNanos的源代码可用;它是在原生Sun库中实现的。

class LockSupport
{
public:
    static void ParkNanos(unsigned __int64 aNanos)
    {
        ULONGLONG start;
        ULONGLONG end;

        ::QueryUnbiasedInterruptTime(&start);
        do
        {
            // My issue with this is that nothing is actually 'Parked'.
            ::SwitchToThread();
            ::QueryUnbiasedInterruptTime(&end);
        }
        while ((end - start) < aNanos);
    }
};

调用代码如下所示：

void SomeClass::SomeFunction()
{
    while (someCond)
    {
        LockSupport.parkNanos(1L);
    }
}

FWIW，我正在将LMAX的Disruptor模式移植到C ++。当一个线程在SingleThreadedClaimStrategy::WaitForFreeSlotAt()而另一个线程在BlockingWaitStrategy::WaitFor（没有超时）时，就会发生死锁。当RingBuffer大小很小时，死锁更明显...... 1,2,4,8等。

线程由普通CreateThread表示。

编辑：我写这篇文章已经很晚了，所以这里有更多信息。 RingBuffer持有__int64个。我有一个Producer线程和一个Consumer线程。 Consumer线程还会生成一个Timer线程，该线程每隔一秒轮询一次Consumer，查看它上次使用的事件的序列号。消费者没有取得进展，生产者也没有完成任务。制作人只是在一个循环中运行几亿次出版一个计数器。所以我的输出看起来像这样：

898
97
131
Timer: no progress
Timer: no progress
...

它只能在发布模式下真正重现，所有内容都针对速度进行了优化。

Answer 1

除了unpark()线程的能力之外，LockSupport.parkNanos(...)只不过是一个睡眠。在Windows上的OpenJDK Hotspot VM中，implemented（第4436行）使用WaitForSingleObject(...)，并且至少休眠1毫秒。

LMAX干扰器似乎永远不会出现unpark()个线程。因此，您应该通过调用Sleep(1)来获得相同的行为。使用Sleep(0)可能会做得更好：您在当前线程中放弃剩余的时间片，并可立即重新安排。这相当于SwitchToThread()，但后者可能只是告诉你“还没有准备好运行，所以你可以保留cpu。”另一方面，如果您的调度粒度足够低，Sleep(1)实际上可能暂停1 ms。

在remarks到Sleep()中，您会注意到您可以通过调用timeBeginPeriod()来改善系统的调度粒度（每个滴答可能只有1毫秒）。

Answer 2

没有parkNanos的源代码可用;它是在原生Sun库中实现的。

该本机库的源代码应该是OpenJDK 6/7源代码的一部分，因此可以下载或浏览。

Windows C ++相当于Java的LockSupport.parkNanos（）

2 个答案: