回调和 'std::recursive_mutex' - 有效的用例

Callbacks and `std::recursive_mutex` - valid use case?

本文关键字：有效 recursive std 回调 mutex      更新时间：2023-10-16

我有以下多态接口：

struct service
{
    virtual void connect(std::function<void>(bool) cb);
      // Invoke 'cb' with 'true' on connection success, 'false' otherwise.
    virtual ~service() { }
};

service的某些实现是同步的：

struct synchronous_service : service
{
    void connect(std::function<void>(bool) cb) override
    {
        cb(true);
    }
};

其他是异步的：

struct asynchronous_service : service
{
    void connect(std::function<void>(bool) cb) override
    {
        _thread_pool.post([this, cb]{ cb(true); });
    }
};

我需要创建一个service包装器，它本身就是一个service。这需要是线程安全的，并在mutex下保持某种状态：

struct wrapped_service : service 
{
    state                    _state;
    std::mutex               _mutex;
    std::unique_ptr<service> _underlying;
    void connect(std::function<void>(bool) cb) override
    {
        std::lock_guard<decltype(_mutex)> guard{_mutex};
        // update `_state`
        _underlying->connect([this, cb]
        {
            std::lock_guard<decltype(_mutex)> guard{_mutex};
            // update `_state`
            cb(true);
        });
        // update `_state`
    }
}

如果_underlying->connect调用始终是异步的，则std::mutex将正常工作。但是，在_underlying->connect同步的情况下，程序将冻结。

这可以通过使用std::recursive_mutex而不是std::mutex来解决，但众所周知，它是一种代码异味。

这是std::recursive_mutex的有效用例吗？

还是设计有缺陷？请注意，我无法控制service界面。

有两种回调模式：即时回调和延迟回调。这要求客户端准备好立即回调并可重入。这使客户端实现复杂化。如果将回调设置为始终延迟，则无需客户端可重入。

相关文章：