繁体   English   中英

在C ++中查询原子变量(布尔)?

[英]Polling for a atomic variable (bool) in C++?

我有一个修改一个原子变量(布尔)的线程,另一个要查询该变量的线程。 我的应用程序在thread A很少进行函数调用,并开始轮询一个特定的原子变量。 Thread B继续读取某些外部应用程序( application on dbus应用application on dbus )的状态,并相应地修改了一些原子变量。 Thread A一个函数希望确保如果返回,则某些外部应用程序已将其状态更改为所需状态,通过这些原子标志可以了解该状态。

我的申请详情:

thread A的函数是start_scan()函数,该函数开始使用dbus API扫描附近的BLE设备。 但是,即使start scan调用成功,但外部应用程序( org.bluez )仍需要一些时间来更新其属性( Property: Discovering )。 我还定义了isScanning类的isScanning ,该函数查询一些变量(在我的应用程序内部)以获取外部应用程序的当前状态。 每当外部应用程序的属性被更新时,它都会通过dbus上的PropertiesChanged信号通知其他应用程序,是的,在成功调用start_scan之后,我要花一些时间(不到一秒钟)才能收到PropertiesChanged信号进行扫描。 因此,我正在考虑在从start_scan函数返回之前轮询本地原子标志(使用自己的超时机制),这将确保如果有人在调用start_scan之后查询扫描状态,则isScanning将返回有效状态。

我不能使用condition_variable,因为我有许多必须位于syn中的函数和标志。

问题:

std::atomic<bool> scanning_;

// Thread A
void start_scan()
{
    // Dbus methods call
    while (scanning_ == false) { // With some timeout
        // Timeout mechanism
    }
}

// Thread B receving asyn signals from DBus
void propertyUpdate(std::string name, bool value)
{
    if (name == "Discovering")
        scanning_ = value;

    ...
}

当线程A轮询scanning_标志时,线程B将接收dbus信号以更新scanning_标志。 我不确定Thread A是否会阻塞线程B,就像它会不断读取该标志并且我的标志是原子的一样? 我想知道如果原子变量变得可用时,如何安排等待原子变量访问的线程?

编辑:

我正在做这样的事情:

    void setter(bool value)
    {
        std::lock_guard<std::mutex lock(mutex_);
        member_ = value;
    }

    bool getter(void)
    {
        std::lock_guard<std::mutex lock(mutex_);
        return member_;
    }

    // Thread A is blocking on a class member value
    while (getter() == false);

    // Thread B will modify the class member when required
    setter(true);

我想知道由于在通用互斥锁上调度阻塞线程而可能遇到的问题。 线程A是否会一直被获取而线程B将永远被阻塞,这是否有可能。 如果在线程A中的getter函数返回之后且线程A再次获取Mutex_之前未计划线程B,则可能会发生这种情况。

如果需要在条件变为真之前阻塞线程(在这种情况下, scanning_带有超时),则应使用条件变量 这样, scanning_将只是一个普通变量,而不是原子变量,并且将受到互斥量的保护。

(可以将原子变量用于某些线程通信,但是您不能仅使用原子变量使线程休眠。在您的示例中,start_scan不断运行,这会占用CPU时间)

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM