C++ 11: std :: hilo dentro de una clase que ejecuta un miembro de función con inicialización de hilo en el constructor

Question

Estoy tratando de usar std :: hilo de C++ 11. No pude encontrar nada si es posible tener un std :: hilo dentro de una clase que ejecuta uno de sus miembros de función. Considere el siguiente ejemplo ... En mi intento (a continuación), la función se ejecuta().

Compilo con gcc-4.4 con -std = C++ 0x marca.

#ifndef RUNNABLE_H 
#define RUNNABLE_H 

#include <thread> 

class Runnable 
{ 
    public: 
     Runnable() : m_stop(false) {m_thread = std::thread(Runnable::run,this); } 
     virtual ~Runnable() { stop(); } 
     void stop() { m_stop = false; m_thread.join(); } 
    protected: 
     virtual void run() = 0; 
     bool m_stop; 
    private: 
     std::thread m_thread; 
}; 


class myThread : public Runnable{ 
protected: 
    void run() { while(!m_stop){ /* do something... */ }; } 
}; 

#endif // RUNNABLE_H 

que estoy recibiendo este error y otros: (mismo error con y sin el $ this)

Runnable.h|9|error: no matching function for call to ‘std::thread::thread(<unresolved overloaded function type>, Runnable* const)’| 

Al pasar un puntero.

Runnable.h|9|error: ISO C++ forbids taking the address of an unqualified or parenthesized non-static member function to form a pointer to member function. Say ‘&Runnable::run’| 

Answer 1

Ese enfoque es incorrecto.

El problema es que, aunque el objeto todavía está en construcción, su tipo todavía no es el tipo más derivado, sino el tipo del constructor que se está ejecutando. Eso significa que cuando inicia el hilo el objeto sigue siendo un Runnable y la llamada a run() se puede enviar al Runnable::run(), que es puramente virtual, y que a su vez causará un comportamiento indefinido.

Peor aún, puede tener una falsa sensación de seguridad, ya que podría suceder que bajo ciertas circunstancias el hilo que se está iniciando demore el hilo actual para completar el constructor Runnable, e ingrese el myThread objeto, en cuyo caso el nuevo subproceso ejecutará el método correcto, pero cambiará el sistema donde ejecuta el programa (diferente número de núcleos, o la carga del sistema, o cualquier otra circunstancia no relacionada) y el programa se bloqueará en producción .

Answer 2

Aquí hay un código para reflexionar sobre: ​​

#ifndef RUNNABLE_H 
#define RUNNABLE_H 

#include <atomic> 
#include <thread> 

class Runnable 
{ 
public: 
    Runnable() : m_stop(), m_thread() { } 
    virtual ~Runnable() { try { stop(); } catch(...) { /*??*/ } } 

    Runnable(Runnable const&) = delete; 
    Runnable& operator =(Runnable const&) = delete; 

    void stop() { m_stop = true; m_thread.join(); } 
    void start() { m_thread = std::thread(&Runnable::run, this); } 

protected: 
    virtual void run() = 0; 
    std::atomic<bool> m_stop; 

private: 
    std::thread m_thread; 
}; 


class myThread : public Runnable 
{ 
protected: 
    void run() { while (!m_stop) { /* do something... */ }; } 
}; 

#endif // RUNNABLE_H 

---

Algunas notas:

• Declaración de m_stop como un simple bool como eras es terriblemente insuficiente; Lea sobre las barreras de memoria
• std::thread::join puede tirar por lo que calificó sin try..catch de un destructor es imprudente
• std::thread y std::atomic<> son no copiable, por lo Runnable deben marcarse como tal, si no por otra razón que para evitar C4512 advertencias con VC++