c++ - 回调和 `std::recursive_mutex` - 有效用例？

Question

我有以下多态接口(interface):

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 接口(interface)。

Answer 1

回调有两种模式:立即和延迟。这要求客户端准备好立即回调并重新进入。这使客户端实现变得复杂。如果您使回调始终延迟，则无需重新进入客户端。