回調和`std :: recursive_mutex`-有效的用例？

Question

我具有以下多態接口：

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接口。

Answer 1

回調有兩種模式：立即和延遲。 這就要求客戶端准備好立即回調並重新進入。 這使客戶端實現變得復雜。 如果您使回調始終被延遲，則無需重新進入客戶端。