使用 boost 轮询状态更改时如何同步线程

Question

在我的应用程序中，我希望通过事件通知另一个应用程序已启动或停止。 我有一个正在运行的应用程序的现有 API无法更改来容纳通知，这将是显而易见的解决方案。

我拥有的是 API 中的函数调用（isRunning），因此我决定创建一个轮询线程，通过 API 轮询状态并通知我的应用程序。

我现在的问题是，轮询线程中的 API 调用使用的对象也在我自己的应用程序的主线程中使用，我想知道如何确保我做得正确:)。

我的想法是用互斥锁包装对 API 对象的每次调用（通过适配器，例如，参见第二个代码块），因此我确信我的线程不会多次调用该 API。

这是正确的方法吗？

我正在使用 boost 进行线程/同步（参见代码）。

这是轮询线程：

void EventCreator::start()
{
    stop();
    m_bShouldRun = true;    
    m_spThread = BoostThreadPtr(new thread(bind(&EventCreator::run,this)));
}

void EventCreator::stop()
{
    {
        lock_guard<mutex> lock(m_mutex);
        m_bShouldRun = false;
        m_condition.notify_one();
    }

    if (m_spThread)
    {
        m_spThread->join();
        m_spThread.reset();
    }    
}

void EventCreator::run()
{
    bool isRTAppRunning = m_pDevice->isApplicationRunning();
    while (m_bShouldRun)
    {
        boost::unique_lock<mutex> lock(m_mutex);
        // 
        if(!m_condition.timed_wait(lock,boost::system_time(boost::get_system_time() + boost::posix_time::milliseconds(25))))
        {
            // here because of time out, so no sleep necessary
            bool isStillRunning = m_pDevice->isApplicationRunning();
            if (isRTAppRunning != isStillRunning)
            {   

                if (isStillRunning)
                {
                    // Using SendMessage to main thread => no problem here
                    notifyAppStarted();
                }
                else
                {   
                    notifyAppStopped(); 
                }
                isRTAppRunning = isStillRunning;
            }
            // in addition to wait above
            m_spThread->yield();
        }
    }
}

这些是来自主线程的一些 API 调用：

void Device::getData(Int32 byteCnt)
{
    mutex::scoped_lock lock(m_monitor);
    m_pApi->fetchBytes(&m_buf,byteCnt);
}

bool Device::isApplicationRunning()
{
    mutex::scoped_lock lock(m_monitor);
    return m_pApi->getState() == DV_RUNNING;
}

Answer 1

这听起来是个好方法。

一般来说，在无争用的情况下，锁的获取速度应该非常快。 您的轮询线程应该不频繁地轮询，即最多每隔几秒轮询一次，因此锁的争用应该非常小。

如果您的两个线程不断争夺锁，您将需要重新考虑您的设计。