Блог

Я хочу иметь базовый класс, целью которого является регистрация его для обратного вызова (и отмена регистрации в деструкторе), обратный вызов — это чисто виртуальная функция. Вот так.

 struct autoregister {
  autoregister() { callback_manager.register(this); }
  ~autoregister() { callback_manager.deregister(this); }
  virtual void call_me()=0;
};
  

Но мне это кажется ненадежным, я подозреваю, что там есть несколько условий гонки. 1) Когда callback_manager видит указатель, call_me по-прежнему не вызывается, и может потребоваться произвольное количество времени, пока объект не завершит построение, 2) к моменту вызова отмены регистрации вызывался деструктор производного объекта, поэтому обратные вызовы вызывать не следует.

Одна из вещей, о которых я думал, заключалась в том, чтобы проверить внутри callback_manager, является ли call_me указателя действительным или нет, но я не могу найти стандартный совместимый способ получения адреса call_me или чего-либо еще. Я думал о сравнении typeid(pointer) с typeid(autoregister *), но между ними может быть абстрактный класс, что делает это ненадежным, derived : public middle {}; middle : public autoregister {};, конструктор middle может потратить час, например, на загрузку SQL или поиск в Google, иобратный вызов видит, что это не базовый класс, и думает, что обратный вызов может быть вызван, и бум. Можно ли это сделать?

Q1: существуют ли другие условия гонки?

Q2: как сделать это правильно (без условий гонки, неопределенного поведения и других ошибок), не запрашивая у производного класса вызов register вручную?

Q3: как проверить, можно ли вызвать виртуальную функцию по указателю?

Вы должны разделить дескриптор обратного вызова и регистрации. Никому, кроме callback_manager, не нужен call_me метод, так зачем держать его видимым извне? Используйте std::function в качестве обратного вызова, потому что это очень удобно: любой вызываемый объект может быть преобразован в него, и лямбды очень удобны. Возвращает Handle объект из метода регистрации обратного вызова. Единственным дескриптором метода будет деструктор, из которого вы удалите обратный вызов.

 class Handle {
public:
    explicit Handle(std::function<void()> deleter)
        : deleter_(std::move(deleter))
    {}

    ~Handle()
    {
        deleter_();
    }
private:
    std::function<void()> deleter_;
};

class Manager {
public:
    typedef std::function<void()> Callback;

    Handle subscribe(Callback callback) {
        // NOTE: use mutex here if this method is accessed from multiple threads
        callbacks_.push_back(std::move(callback));
        auto itr = callbacks_.end() - 1;
        // NOTE If Handle lifetime can exceed Manager lifetime, store handlers_ in std::shared_ptr and capture a std::weak_ptr in lambda.
        return Handle([this, itr]{
            // NOTE: use mutex here if this method is accessed from multiple threads
            callbacks_.erase(itr);
        });
    }

private:
    std::list<Callback> callbacks_;
};
  

Q1: существуют ли другие условия гонки?

Обратный вызов / дескриптор может пережить callback_manager и попытается отписаться от удаленного объекта. Это может быть исправлено либо политикой (всегда отменяйте подписку на все перед удалением manager), либо с помощью слабых указателей.

И существует очевидная гонка, если callback_manager доступ осуществляется из нескольких потоков, вам нужно защитить хранилище обратных вызовов с помощью мьютексов.

Q2: как сделать это правильно (без условий гонки, неопределенного поведения и других ошибок), не запрашивая у производного класса вызов register вручную?

Смотрите выше.

Q3: как проверить, можно ли вызвать виртуальную функцию по указателю?

Это невозможно.

В конструкторе вашего авторегистратора, поскольку объект еще не полностью сконструирован, указатель ‘this’ опасно передавать callback_manager. Я бы рекомендовал немного другой дизайн.

 struct callback {
  virtual void call_me() = 0;
}

struct autoregister {
  callback*const callback_;

  autoregister(callback*const _callback)
    : callback_(_callback) {
    callback_manager.register(callback_);
  }

  ~autoregister() {
    callback_manager.deregister(callback_);
  }
};
  

Q1: существуют ли другие условия гонки?

Возможно. Ваш callback_manager должен быть синхронизирован, если его могут использовать несколько потоков. Но моя версия autoregister сама по себе не имеет условия гонки.

Q2: как сделать это правильно (без условий гонки, неопределенного поведения и других ошибок), не запрашивая у производного класса вызов register вручную?

Я думаю, что мой код может сделать это правильно.

Q3: как проверить, можно ли вызвать виртуальную функцию по указателю?

В моем коде нет необходимости. Но в целом вы могли бы сохранить в классе флаг, который имеет значение false в списке инициализации и значение true при готовности к вызову.

Условие гонки — это когда два потока пытаются что-то сделать одновременно, и результат зависит от точного времени. Я не думаю, что в этом фрагменте есть условие гонки, потому this что оно доступно только потоку, выполняющему конструктор. Однако может быть условие гонки callback_manager , но вы не опубликовали код для этого, поэтому я не могу сказать.

Здесь есть еще одна проблема: объекты создаются от базового до самого производного, поэтому во время autoregister выполнения конструктора виртуальный call_me не может быть вызван. См. Эту запись часто задаваемых вопросов. Невозможно проверить, будет ли работать вызов виртуальной функции, кроме обеспечения полной сборки класса.

Любое решение этой проблемы, которое работает по наследованию, не может гарантировать, что регистрируемый класс будет полностью сконструирован до регистрации обратного вызова, поэтому регистрация должна выполняться извне по отношению к регистрируемому классу. Лучшее, что вы можете сделать, это иметь некоторую оболочку RAII, которая регистрирует объект при создании и отменяет его регистрацию при уничтожении, и, возможно, принудительно создавать объекты через фабрику, которая обрабатывает регистрацию.

Я думаю, что @Donghui Zhang на правильном пути, но, так сказать, еще не совсем там. К сожалению, то, что он сделал, содержит свой собственный набор подводных камней — например, если вы передаете адрес локального объекта в autoregister ctor, вы все равно можете зарегистрировать объект обратного вызова, который немедленно выходит из области видимости (но не обязательно сразу же снимается с регистрации).

Я также думаю, что сомнительно (в лучшем случае) определять интерфейс обратного вызова, используя call_me его в качестве функции-члена для вызова при обратном вызове. Если вам нужно определить тип, который можно вызывать как функцию, C уже определяет имя для этой функции : operator() . Я собираюсь применить это вместо call_me того, чтобы присутствовать.

Чтобы сделать все это, я думаю, вы действительно хотите использовать шаблон вместо наследования:

 template <class T>
class autoregister {
    T t;
public:
    template <class...Args>
    autoregister(Args amp;amp; ... args) : t(std::forward(args)...) {
       static_assert(std::is_callable<T>::value, "Error: callback must be callable");

       callback_manager.register(t);
    }

    ~autoregister() { callback_manager.deregister(t); }
};
  

Вы бы использовали это примерно так:

 class f {
public:
     virtual void operator()() { /* ... */ }
};

autoregister<f> a;
  

static_assert Гарантирует, что тип, который вы передаете в качестве параметра шаблона, может вызываться как функция.

Это также поддерживает передачу аргументов в autoregister конструктор для объекта, который он содержит, поэтому у вас может быть что-то вроде:

 class F {
public:
    F(int a, int b) { ... }
    void operator()() {}
};

autoregister<F> f(1,2);
  

…и 1, 2 будет передан через from autoregister to F , когда он будет создан. Также обратите внимание, что это не пытается принудительно применить определенную сигнатуру для функции обратного вызова. Если бы вы, например, модифицировали свой менеджер обратного вызова для выполнения обратного вызова as int r = callback(1); , тогда код компилировался бы только в том случае, если зарегистрированные вами объекты обратного вызова могут быть вызваны с int аргументом и возвращены an int (или что-то, что может быть неявно преобразовано в an int , в любом случае). Компилятор принудительно выполнит обратный вызов, имеющий подпись, совместимую с тем, как он вызывается. Единственным большим недостатком здесь является то, что если вы передаете тип, который может быть вызван, но (например) не может быть вызван с параметрами, которые пытается передать менеджер обратного вызова, сообщения об ошибках, которые вы получаете, могут быть не такими удобочитаемыми, как хотелось бы.