Início / coding / Perguntas / 77780887
Accepted
Damir Tenishev
Asked: 2024-01-08 21:55:16 +0800 CST

É seguro alterar o ponteiro enquanto ele é usado para chamadas de funções virtuais em outros threads?

  • 772

Em um aplicativo multithreading, dois ou mais threads paralelos usam um ponteiro para chamar uma função virtual. Ao mesmo tempo, em outro thread, esse ponteiro muda para outro objeto. Isso é seguro ou devo tomar medidas para torná-lo seguro?

Considere o código:

class Scene {
public:
  virtual void render() const = 0;
  virtual void update() const = 0;
};

class D1: public Scene {
    // members
public:
  virtual void render() const { /* work with D1 members */ }
  virtual void update() const { /* work with D1 members */ }
};

class D2: public Scene {
    // members
public:
  virtual void render() const { /* work with D2 members */ }
  virtual void update() const { /* work with D2 members */ }
};
// …somewhere in thread 1
Scene *scene=new D1;
…
Scene *scene=new D2;
// … somewhere in thread 2
scene->render();
// … somewhere in thread 3
scene->update();

Por que considero arriscado

Se a chamada de função virtual não for uma operação atômica, posso imaginar a situação em que o compilador leva o ponteiro para o objeto (para ser passado implicitamente é this ) em uma etapa e se refere à chamada de função virtual em outra etapa, lendo novamente esse ponteiro da memória . Entre essas etapas o ponteiro pode ser alterado em outro thread e isso pode acabar com o método D2::render chamado para o objeto D1.

Eu nem tenho certeza de que tornar esse ponteiro volátil ajudaria o compilador a corrigir isso, já que é uma chance de o compilador usar essa dica para outros propósitos.

Minha solução simples

Uma solução simples para isso seria usar uma cópia intermediária:

// … somewhere in thread 2
Scene* safe_copy_scene = scene;
safe_copy_scene->render();

A questão é: é necessário ou a chamada de função virtual pode ser considerada atômica nesta perspectiva e isso é garantido por padrão e não depende de compilador/otimização?

c++

2 respostas

  1. Ao mesmo tempo, em outro thread, esse ponteiro muda para outro objeto. Isso é seguro ou devo tomar medidas para torná-lo seguro?

    Não, não é seguro fazer o ponteiro apontar para outro objeto sem sincronização e sim, você deve tomar medidas para torná-lo seguro para threads.

    Uma maneira é torná-lo atômico:

    std::atomic<Scene*> scene;

    Observe, porém, que se vários threads estiverem chamando constfunções não membros no mesmo Sceneobjeto, você também precisará torná-los thread-safe.

    Você também precisa manter referências às cenas para que elas possam ser destruídas adequadamente quando você terminar com elas e elas não devem ser destruídas antes que qualquer thread que possa acessá-las tenha a garantia de não fazer mais tais acessos.

    auto scene1 = std::make_unique<Scene>(); // thread 1
auto scene2 = std::make_unique<Scene>(); // thread 2

    Você pode então mudar a cena ativa com:

    scene = scene1.get(); // thread 1
scene = scene2.get(); // thread 2

// any thread after `scene` has stored a scene*:
void func() {
    auto& active_scene = *scene; // picks scene1 or 2
    active_scene.foo();
    //...
    active_scene.bar();          // still the same scene you called foo on
}
    • 3
  2. Best Answer

    Não é seguro, é uma corrida de dados e resulta em comportamento indefinido.

    Imagine um cenário tão ruim:

    T1: Scene *scene=new D1
T2: reads vtbl of D1 pointed by scene
T1: scene=new D2
T2: calls D1::render() and passes this pointing to D2.

    A solução alternativa não é segura, porque o compilador pode otimizar a safe_copy_scenevariável.

    Isso é seguro:

    std::atomic<Scene*> scene=new D1;
// …
scene=new D2;
// … somewhere in thread 2
scene->render();
// … somewhere in thread 3
scene->update();

    As operações atômicas sequenciadas com barreiras não permitirão a leitura vtblprévia scenede this.

    • 3

relate perguntas