I'm trying to pass a virtual method to the thread class' constructor (C++ thread).
After searching all over, I've only been able to pass a non-virtual member method.
My base class A has a start method as follows:
void A::start() {
thread(&A::runnable,A()); // <--- What do I change here?
}
The function runnable is virtual and is also implemented in derived class B.
I override runnable in derived class B.
I then invoke start on B.
Obviously, and undesirably, the start function uses runnable implemented in A (instead of B) because it is explicitly defined in A::start.
Is there any way to let the runnable function be dynamically bound?
I thought of using templates and a couple of other creative solutions. (I eventually will implement start in B if there are no real solutions)
Any help would be greatly appreciated.
Obviously, and undesirably, the start function uses runnable implemented in A (instead of B) because it is explicitly defined in A::start.
This could be obvious to you, but it is incorrect. When you create a thread you pass an unnamed temporary instance of class A, which obviously has type A so A::runnable would be always called, but you should pass this:
void A::start() {
thread(&A::runnable,this); // <--- What do I change here?
}
Then proper virtual function would be called.
See Boost::Bind and virtual function overloads: why do they work? for details why.
There are a couple of things to address.
First in A::start() you create an anonymous local thread object. Unfortunately, this object will be destructed as soon as you leave A::start(). This will trigger an abort.
When you create a thread object you must always either join() it or detach() it before the object gets destructed.
For the rest of the answer, I'll use a private thread t in A:
class A {
...
protected:
thread t; // default constructed thread object, i.e. without associated thread of execution
public:
...
~A() {
if (t.joinable()) // If thread active and not detached, be sure that it's joined before it is destructed !!
t.join();
}
....
};
Next, in your thread creation, you use A() as parameter. This means that you will create a new anonymous A object and pass it as argument. I guess it's not what you intend to do, so you use this instead.
Then, as was told by Slava, when &A::runnable is used in combination with this, it is the virtual function that is called. So start() should look like:
void start() {
t = move (thread (&A::runnable, this )) ; // Here I create an anonymous thread and move it to t.
}
If your run this code, you'll notice that A::runnable() is called for class A objects and B::runnable() for class B objects.
Related
I just had to put in a fix for a difficult-to-find error, but I am not happy about the fix. Our application is C++ running in Windows, and the error was a pure virtual call crash. Here is some background:
class Observable
{
public:
Observable();
virtual ~Observable();
void Attach(Observer&); // Seize lock, then add Observer to the list
void Detach(Observer&); // Seize lock, then remove Observer from the list
void Notify(); // Seize lock, then iterate list and call Update() on each Observer
protected:
// List of attached observers
};
class Subject : public Observable
{
// Just important to know there is a subclass of Observable
}
class Observer
{
public:
Observer();
virtual ~Observer(); // Detaches itself from the Observable
void Update() = 0;
};
class Thing : public Observer
{
public:
void Update(); // What it does is immaterial to this question
};
Because this is a multi-threaded environment, there are locks in place for Attach(), Detach(), and Notify(). Notify() seizes the lock and then iterates the list of observers and calls Update() on each one.
(I hope this is enough of a background without having to post the complete body of code.)
The problem arose when an observer was being destroyed. On destruction, the Observer detaches itself from the Observable. At the same time, in another thread, Notify() is being called on the Subject. My original thought was that we were protected because of the locks in Detach() (called on destruction of the Observer), and Notify(). However, C++ destroys the subclass first, then the base class. This meant that, before the lock in Detach() was obtained which would have prevented the Notify() function from continuing, the implementation of the pure virtual Update() function was destroyed. The Notify() function continued (because it had already obtained the lock) and attempted to call Update(). The result is a crash.
Now, here is my solution, which works, but gives me a queasy feeling. I changed the Update() function from being pure virtual to just being virtual and provided a body that did nothing. The reason this bothers me is that Update() is still being called, but on a partially destructed object. In other words, I am getting away with something, but I am not wild about the implementation.
Other options discussed:
1) Move the locking into the subclasses. Not desirable because it forces the developer of each subclass to duplicate the logic. And if he omits the locking, bad things can happen.
2) Force the destruction of the observer to occur via a Destroy() function. Honestly, I wasn't sure how to implement this for stack-based objects.
3) Have the subclass call a "PreDestroy()" function in its destructor to notify the base class that destruction is imminent. I wouldn't know how to force this, and forgetting it could lead to hard-to-find runtime errors.
Can anyone offer any suggestions as to a better way to protect against these types of crashes? I have this unpleasant feeling that I am missing the elephant in the room.
JAB
This problem is an illustration of a more general consequence of multi-threaded design: no object that is affected by multiple threads can provide a guarantee of no concurrent access to itself at any point in time. This consequence is the elephant in the room that is giving you the unpleasant feeling you describe at the end of your question.
In short, your problem is that Attach(), Detach(), and Notify() are responsible for both grabbing the appropriate lock and doing their thing. They need to be able to assume the lock is grabbed before they are called.
Unfortunately, the solution requires a more complicated design. It is necessary for some single source that is independent of your objects (or classes) to mediate the construction, updating (including attaching and detaching), and destruction of all your objects. And it is necessary to prevent any of those processes from occurring independently of the mediator.
It is a design choice whether you prevent those processes by technical means (e.g. access control, etc) or simply state policies that all your types must comply with. That choice depends on whether you can rely on your developers (including yourself) to follow policy guidelines.
About your solutions:
Not good, because of the reasons you give.
Ok. Additionally, define ~Observer() as protected (as any other destructor of derived classes) to avoid calling delete directly and write a member void Destroy(). The problem is that it will not work for automatic (local) variables. Actually, with a protected destructor you will not be able to declare local variables.
You probably mean calling PreDestroy() from the destructor of each subclass destructor. The problem will be not to forget it (you can assert that it has been called from ~Observer()) and if you have several levels of inheritance.
About your original solution:
Making Update() a callable virtual function seems to work, but it is technically wrong. While one thread is calling the virtual Update(), using the vtable pointer, another thread is calling ~Thing() and updating the vtable pointer to that of Observer(). The first thread holds the lock, but the second one does not, so you have a race.
My advice would be use option 2 unless you are very fond of automatic instances of subclasses of Observer.
If you are willing, you could try with templates:
template<typename O>
class ObserverPtr : Observer
{
public:
ObserverPtr(O *obj)
:m_obj(obj)
{}
void Update()
{
m_obj->Update();
}
~ObserverPtr()
{
PreDestroy();
delete m_obj;
}
private:
O *m_obj;
};
And then Thing will not derive from Observer.
You can also create alternative variants of this template:
to hold a reference to the real observer instead of a pointer (O &m_obj;). No use of delete.
to define the real observer as an actual member (O m_obj;). No dynamic allocations.
to hold a smart pointer to the real observer.
I think that unless you mandate to call Detach from the derived class destructor, it will not have an easy solution.
One solution which comes into my mind might be to utilize an extra "wrapper" which will take care of de-registration (and might actually do the registration as well).
Something like this (for example):
class ObserverAgent;
// the wrapper class - not virtual
class Observer
{
public:
Observer(Observable &subject, ObserverAgent &agent)
: _subject(subject), _agent(agent)
{
_subject.Attach(*this);
}
~Observer()
{
_subject.Detach(*this);
}
void Update()
{
_agent.Update();
}
private:
Observable &_subject;
ObserverAgent &_agent;
};
// the actual observer polymorphic object
class ObserverAgent
{
public:
ObserverAgent();
virtual ~ObserverAgent();
protected:
// only callable by the Observer wrapper
friend class Observer;
virtual void Update() = 0;
};
class Thing : public ObserverAgent
{
public:
virtual void Update();
};
The use is then indeed more convoluted:
Subject s;
{ // some scope
Thing t;
Observer o(s, t);
// do stuff
} // here first Observer is detached and destroyed, then Thing (already unregistered)
Note that you cannot Attach/Detach Thing (ObserverAgent) directly, only through Observer (because Observable takes the Observer, not the ObserverAgent).
Perhaps it could be possible to wrap it in a single class for simpler use (Agent being an inner class of the Observer), however then there might be problems with the lifetime of the agents (as the destruction of the Observer would have to be virtual again).
Why not expose the lock as protected in Observable? Observable::~Observable acquires the lock if it's not acquired already by this thread, then goes on with the cleanup. Meanwhile EVERY subclass of Observable acquires the lock in its dtor without further releasing it (which is only done in ~Observable itself).
Frankly, in this design the simplest and the most consistent solution seems to manually Detach() each Observer at the very start of the most derived class' destructor. I don't see how this can be automated, and since something has to be done at the dawn of destruction, why not detachment.
...Well, if we don't need to go deeper:
template<class Substance> struct Observer {
Observer(Observable &o): o(o) { o.attach(s); }
~Observer() { o.detach(s); }
Substance &subst() const { return s; }
private:
Observable &o;
Substance s;
};
struct ThingSubst { void update(); long stats(); };
typedef Observer<ThingSubst> Thing;
Observable o;
Thing thing(o);
std::cout << thing.subst().stats() << std::endl;
I have a stack with threads using Boost. I have 2 classes with method run, for example:
class class1 {
public:
class1::class1(){
void run() { //I need to call getA
}
}
};
class class2 {
private:
float A;
public:
class2:class2() { A = 0; }
void run() { A++; }
float getA() { return A; }
};
In the main function, I have both run's methods as threads:
void main(){
class1 c1;
class2 c2;
boost::thread t1(&class1::run,c1);
boost::thread t1(&class2::run,c2);
t1.join();
t2.join();
}
I've unsucesfully tried using a mutex. I've also created a pointer of c2 into c1, but the value is not updated.
How could one class call a method in another class when their instances are in different threads?
Firstly, some clarifications:
Classes are not objects in C++, they are mere compile-time constructs to group related stuff. So, "how could one class" should rather be "how could one instance" or "one class".
Further, "when their instances are in different threads" doesn't make sense either, because threads (as opposed to processes) share the same memory space. However, you still need to reach the other object, for which you need a reference, which you somehow need to pass along.
Lastly, to "Call [a] Method in other Boost Thread" is ambiguous. It could mean you want to invoke a method on a different object, which would be called by the same thread though. It could also mean that you want a different thread to call the method and then return the result to your thread, which is way more complicated. That would require some form of communication with that other thread.
Now, in order to get objects passed to a thread function, check out e.g. Boost.Bind. Since it doesn't matter that these things are called in a thread, you could also pass a reference to the class2 instance to the ctor of class1 and store it there. Much of that depends on what you actually want. However, one note still: If you share objects between threads, you will have to sync access to them somehow, e.g. using a mutex.
PS: C++11 has its own threads which I would prefer over Boost.Thread. They are mostly the same, but one of them is standard, while Boost still is an addon.
I'm new to C++, and I'm learning Qt.
Consider this line:
connect(ui->horizontalSlider, &QSlider::valueChanged,
ui->progressBar, &QProgressBar::setValue);
What I don't understand is why you pass the address of a static (is it static?) method valueChanged (&QSlider::valueChanged) instead of the current object method address &ui->horizontalSlider->valueChanged. Although I can use this second option that works too.
You pass the address of the member function which should be called.
The member function is not static though, that means it needs an object to work on.
class MyClass
{
void aFunction();
}
here MyClass::aFunction is a member function.
What the compiler creates is similar to this
class MyClass
{
static void aFunction(MyClass *this);
}
So whenever you call aFunction like my_instance.aFunction() the this pointer will be handed over implicitly, so the call basically becomes MyClass::aFunction(&my_instance).
As a result the address of aFunction is the same for every instance of MyClass.
Yet to execute aFunction you need an instance of MyClass.
This is why in your case you have to provide connect with both the instance ui->horizontalSlider as well the function to be called on it &QSlider::valueChanged.
What I described is an oversimplification so take it with a grain of salt.
Moreover when you have virtual functions things change.
duplicate of: "pure virtual method called" when implementing a boost::thread wrapper interface
I am trying to create a more object oriented version of the threads using boost threads.
So I created a Thread class:
class Thread {
public:
Thread() {}
virtual ~Thread() { thisThread->join(); }
void start() { thisThread = new boost::thread(&Thread::run, this); }
virtual void run() {};
private:
boost::thread *thisThread;
};
this class creates the thread in start()
like this:
thisThread = new boost::thread(&Thread::run, this);
The problem is that when I create a class that overwrites the run() method, the run() method from Thread is call by the thread instead of the new run() method
for example I have a class that extends Thread:
class CmdWorker: public Thread {
public:
CmdWorker() : Thread() {}
virtual ~CmdWorker() {}
void run() { /* deosn't get called by the thread */ }
};
when I do
Thread *thread = new CmdWorker();
thread.start(); //---> calls run() from Thread instead of run() from CmdWorker
but just to be more clear:
thread.run(); calls the correct run from CmdWorker, (run() is virtual from Runnable)
Any idea why this happens or how it can be fixed ?
NOTE:
I created a function (that has nothing to do with the Thread class)
void callRun(Thread* thread) {
thread->run();
}
and changed the thread creation to:
thisThread = new boost::thread(callRun, this);
when debugging I noticed that the thread pointer is pointing to a object of type Thread instead of CmdWorker
EDIT:
testcase code at: http://ideone.com/fqMLF
and http://ideone.com/Tmva1
Object seems to be sliced (but this is strange since pointers are used)
didn't manage to add boost to it
The answer is in that question:
"pure virtual method called" when implementing a boost::thread wrapper interface
Basically, when the boost::thread object begins running, the object it was run against had the
time to be deleted.
You have to implement a join method that you call manually before destroying the object.
when debugging I noticed that the thread pointer is pointing to a
object of type Thread instead of CmdWorker
Maybe the CmdWorker object is sliced (i.e. copied by value) into a Thread object somewhere in your code?
Do you get the same behaviour with a minimal test case?
By doing &Thread::Run on a non-virtual function, you are forcing any class that derives from Thread to use the function specified in the Thread base class. Try making Thread::Run a virtual void and see if that fixes your issue.
From reading your updates, you're calling delete in the main thread, while the thread is starting in the other. Depending on the race between the destructor and the invocation of run, it will either:
Crash before it starts, because the vtable is completely destroyed
Call the Thread::run (which is pure virtual, and crashes with a pure virtual thunk)
Call the correct function, which is the derived class run()
If you add a call to sleep(1) after you call start, but before you call delete, you'll find that it works as you expect.
Does anyone know any trick I could use to keep the Derived class until the base class destructor have been called?
i.e:
#include <iostream.h>
class Base
{
public:
Base(){ cout<<"Constructor: Base"<<endl;}
virtual ~Base(){ cout<<"Destructor : Base"<<endl;}
};
class Derived: public Base
{
//Doing a lot of jobs by extending the functionality
public:
Derived(){ cout<<"Constructor: Derived"<<endl;}
~Derived(){ cout<<"Destructor : Derived"<<endl;}
};
void main()
{
Base *Var = new Derived();
delete Var;
}
This will result in Derived class to be destroyed, then Base class will be destroyed.
The reason I need something like this is I have a custom Event(signal/slot) class.
The Event class provide an Observer class.
If I define :
class A : public Event::Observer
and then delete an instance of class A, when the ~Observer automatically remove any signal connected to this observer.
But since Class A is destroyed before the Observer, if something on a different thread call a slot on A after ~A and before ~Observer get called. Everything goes to hell...
I can always call the Observer.release method from the ~A, which fix the timing issue. But it was cleaner if I wouldnt need to.
Any ideas?
You definitely don't want to change destruction order, which is good, because you can't.
What you really want to do is to dispose/disconnect/shutdown the Observer.
What I would do is add this to your Event::Observer class:
void Event::Observer::Shutdown()
{
if(!isShutdown)
{
//Shut down any links to this observer
isShutdown = true;
}
}
void ~Event::Observer()
{
Shutdown();
//rest of Event::Observer destruction
}
and then:
~A()
{
Shutdown();
//clean up any other A resources
}
If you did something like IDisposable suggested by David, that would work too -- just call Observer::Dispose() in your destructor for class A.
My code all assumes that you have only a single thread accessing these objects. Thread synchronization is an entirely separate subject.
Destructors work as they are expected to do and you should not touch them (actually, you can't change the calling order). As for your task - you need proper threads synchronization. As a simplest solution: unsubscribe your observer before deleting it.
I suggest you either implement reference counting or an IDisposable interface and use it as a convention amongst your clients. Whether or not you call Observer::Release() in your A::dtor(), YOu're talking about having a different thread come in and call a method on an object that is being destroyed. That is definitely a race condition, you should never have code from another thread asynchronously executing on a method on an object that is being destroyed.
With reference counting, the event subscriber objects don't get deleted until they are unregistered. With an IDisposable pattern, you make sure to remove any references to an object before the destructor is called. Either could be appropriate depending on your architecture.
Base class destructor always gets called after derived class destructor. You mustn't call any of object's methods from other threads after object's destructor begins execution (regardless of whether it has a base class or not). I'd suggest using a new class that works as a container for class Base instances and implements a safe access to Base's objects (you probably need to use one of synchronization objects to implement id).
You cannot change the order of destruction in an inheritance relationship and that's good (what would a Derived be once its Base was destroyed?. However, you can change the relationship.
For example you could always wrap Derived in a class (template) which calls release() first before destroying Derived.
It's a typical race condition, it's just that this one is glaring.
There are obviously several methods at your disposal. You could for example have a mutex in the Base class and lock it as soon as you enter the destructor of the most derived class... however as you noted it's difficult.
I would suggest making the destructor protected (for each class in the hierarchy) and have a method to invoke for destruction (objects cannot be allocated on the stack any longer), then overload delete for the Base class, and have it unregister your object first before destroying it by calling this special method.
The only issue is that anyone not respecting the make your destructor protected bit will screw things up.
On the other hand, you could also NOT use inheritance, and prefer composition instead. This would allow you to control the destruction order of the various attributes.