When I call QNetworkAccessManager::get() or QNetworkAccessManager::post() or many other methods the program flow continues on after the call and if I want further interaction, like getting what was received from the server, I need to use signals/slots. Do these functions run in their own thread? But the times I have used threads I have had to call something like MyClass::start() which doesn't happen when I call get() or post().
The times I have built a threaded class, the only way to start a function in the class is through MyClass:start() and MyClass::run(). But right now I have a class that has all sorts of functions in it that get called, and these functions should run in the background so that the main application can later receive a signal from those functions.
Hypothetically I'd have something like this
class MyClass
{
public:
void func1();
void func2();
};
MyClass::func1()
{
// move off into other thread
// do stuff
emit signal1(data1)
}
MyClass::func2()
{
// move off into other thread
// do stuff
emit signal2(data2)
}
I should be able to access MyClass::func1 or func2 directly which would be cumbersome if the only was to access them were through MyClass::start().
I hope this makes sense, I'm more a php person, these things are a bit foreign to me.
In sum, I'm looking to have a class, with multiple public functions all of which can be called on their own thread. I think. Maybe I'm on the wrong track.
Related
I have written up a framework for threaded objects with the following very basic structure:
class ThreadedObject {
public:
ThreadedObject(Thread* parentThread);
protected:
virtual void initialize();
}
class MyThreadedObject {
public:
MyThreadedObject(Thread* parentThread) : ThreadedObject(parentThread) {}
protected:
void initialize() override;
}
I have a mechanism whereby I don't call methods of subclasses of ThreadedObject's directly, instead I pass them onto a queue (via std::function) to be executed within the correct thread (parentThread).
I ran into an issue with the initialize method. The intent of this method is to act as a thread-conscious "constructor." What I mean is, since a ThreadedObject can be created in ANY thread, that means its constructor will run in the thread is was created in. However, I want the initialization (that would normally be in the constructor) to occur within the parent thread of the ThreadedObject instance.
The simplest solution to this problem would be:
Thread myThread();
MyThreadedObject myObject(&myThread);
invoke(&myObject, &MyThreadedObject::initialize);
Assuming the invoke method looks at what thread is assigned to myObject and queues a call to initialize within that thread.
However, I am wondering if there is any way to have this happen automatically AFTER the object has been constructed. My naive solution was to do the following:
ThreadedObject::ThreadedObject(Thread* parentThread) {
//...
invoke(this, &ThreadedObject::initialize);
}
However, I learned quickly that you can't call a virtual method like this from within the constructor of a base class.
It looks to me as if I need some way to call initialize AFTER all the layers of constructors (base -> child 1 -> child 2 -> ...) have completed.
Is something like this possible?
Thanks!
EDIT
I found an article about the same problem here: Is there any automated way to implement post-constructor and pre-destructor virtual method calls?
I am wondering if my real question then becomes, is there a way to wrap the construction of ThreadedObjects and their child classes in some sort of critical section so that construction completes before any other threads can take over?
i have an encoder class with lots of methods . this is a subclass of Qthread. i am new to multi-threading and
trying to understand how this class is
threading its methods
... i understand to thread a method it has to be in a subclass of qthread. and the run of this implements the threaded code for this class. And the thread starts only when a call to start method on the object of this class is made.
Question : firstly what do you infer
from the this run implementation
void Encoder::run(void)
{
VERBOSE(VB_DEBUG, "Encoder::run");
if (WILL_PRINT(VB_DEBUG))
print_stats_timer_id = QObject::startTimer(kEncoderDebugInterval);
health_check_timer_id = QObject::startTimer(kEncoderHealthCheckInterval);
if (init())
exec();
else
VERBOSE(VB_ERROR, "Encoder::run -- failed to initialize encoder");
QObject::killTimer(health_check_timer_id);
if (print_stats_timer_id)
QObject::killTimer(print_stats_timer_id);
cleanup();
}
Question: what does thread context mean in
relation to its methods .
also
Question: what would happen If a method of this
class is called before this class's
thread has started
The class you have written creates a thread and initializes a QObject::timer. It then goes on to call a user defined init() function then the QThread::exec() function.
My guess is that you intended that exec() would be a user defined function where the actual work is to occur. Be aware that QThread::exec() processes the thread's Qt Event Queue.
Also, on some platforms you may get an "Error creating timer from thread" warning message. I've encountered this error on Windows when the code executed fine on Linux
Also, be aware that your timer will never occur if you do not call the QThread::exec() function or QApplication::processEvents() from within your thread.
Thread context in Qt is the same as any other thread concept. That is, all memory is shared between the threaded code (entered at this point in your "run()" function). And any other context which calls into your object. If this object may ever be executing in a thread and accessed from outside of the thread you must protect the shared data.
Because all data is shared between thread contexts (it's a shared memory multiprocessing model) there is no problem with calling functions before/after/during thread execution. Given that:
The object is fully constructed before you call any method. This is not special to threads, necessarily, unless the object is created in a thread.
Any data member is protected with a mutex lock (I eluded to this in #2). QMutexLocker is a handy stack based RAII way of dealing with mutex locks in Qt.
I believe I fully answered your question here, so I'll go ahead and link to RAII and threading articles I have written on another site, just for further reference.
Edit: specificity about threading scenarios:
class MyThreadedClass : public QThread
{
MyThreadClass(const boost::shared_ptr<SomeOtherClass> &t_object)
: m_object(t_object) {}
void doSomething()
{
// Depending on how this method was called (from main, from internal thread)
// will determine which thread this runs on, potentially complicating thread
// safety issues.
m_object->someThing();
}
void run()
{
// I'm now in a thread!
m_object->someFunction(); // oops! The call to someFunction is occurring from
// a thread, this means that SomeOtherClass must be
// threadsafe with mutex guards around shared
// (object level) data.
// do some other stuff
}
};
int main()
{
MyThreadClass thread(someobjectfromsomewhere);
thread.start(); // MyThreadClass is now running
thread.doSomething(); // The call to doSomething occurs from main's thread.
// This means 2 threads are using "thread", main
// and "thread"'s thread.
// The call to thread.doSomething hits Thread.m_object, which means that
// now multiple threads are also accessing m_object ("thread" and "main").
// This can all get very messy very quickly. It's best to tightly control
// how many threads are hitting an object, and how
}
NOTE: It would be a good idea to investigate QFuture, which is designed to handle this kind of asynchronous task, like an encoder, that you are looking at QFuture will avoid some of the potential threading issues of shared data and deadlocks.
I'm totally new to programming with threads, and since the class is using QThreads, I'm wondering why I cannot call a QThread's start function from within itself and have its run function start executing independently of another thread (the program seems to crash when I do this). Instead, I have to call the start function from wherever the object was declared. Why is this?
Some code:
class ClassWithThread : public QThread
{
public:
ClassWithThread() {}
someFunction() {start();}
run()
{
//do some stuff here
}
}
That is basically what my class does. When I call someFunction the program crashes. If I remove the start statement from someFunction though, and call start from outside the program, then it works fine.
QThread should be derived only if you want to extend thread capability, not to specialize it for your job like this. This article would help you to understand the use of QThread.
So you must create a QThread and start it from outside and then move an object to it that will do the job. Read this example: http://labs.qt.nokia.com/2006/12/04/threading-without-the-headache/
Hope that helps to avoid this kind of problem
I am using Qt and wish to write a class that will perform some network-type operations, similar to FTP/HTTP. The class needs to connect to lots of machines, one after the other but I need the applications UI to stay (relatively) responsive during this process, so the user can cancel the operation, exit the application, etc. My first thought was to use a separate thread for network stuff but the built-in Qt FTP/HTTP (and other) classes apparently avoid using threads and instead rely on signals and slots. So, I'd like to do something similar and was hoping I could do something like this:
class Foo : public QObject
{
Q_OBJECT
public:
void start();
signals:
void next();
private slots:
void nextJob();
};
void Foo::start()
{
...
connect(this, SIGNAL(next()), this, SLOT(nextJob()));
emit next();
}
void Foo::nextJob()
{
// Process next 'chunk'
if (workLeftToDo)
{
emit next();
}
}
void Bar::StartOperation()
{
Foo* foo = new Foo;
foo->start();
}
However, this doesn't work and UI freezes until all operations have completed. I was hoping that emitting signals wouldn't actually call the slots immediately but would somehow be queued up by Qt, allowing the main UI to still operate.
So what do I need to do in order to make this work? How does Qt achieve this with the multitude of built-in classes that appear to perform lengthy tasks on a single thread?
If you're doing a length job in the UI thread the UI is going to freeze. One way to avoid this is to call once in a while QCoreApplication::processEvents().
You should be VERY careful however to understand what this does before you decide to do it. Calling this function means that a GUI event can fire in the middle of your operation. If this event can in turn create some more jobs you can end up starting a new job while in the middle of the old job.
I wouldn't be so quick dismissing the worker thread approach. It has the advantage of completely separating the work from the GUI so you are certain that something that began is going to finish.
You should also consider that Windows especially sometimes introduces non trivial delays to GUI loops. If the host is somewhat busy or in a memory thrashing state you'll find that GUI events may take up to several long seconds to finish and return control to your processing.
Use QThread with a run method like this:
void run(){ exec(); }
this will provide another execution loop, where you can do your "hard work" without acutally freezing the UI.
Note: Make sure to actually use the thread's execution loop by adding
moveToThread(this);
at the end of the Constructor of your QThread derived Thread class (the doc doesn't say much about it)
I have a class which is not thread safe:
class Foo {
/* Abstract base class, code which is not thread safe */
};
Moreover, if you have foo1 and foo2 objects, you cannot call foo1->someFunc() until foo2->anotherFunc() has returned (this can happen with two threads). This is the situation and it can't be changed (a Foo subclass is actually a wrapper for a python script).
In order to prevent unwanted calls I've created the following -
class FooWrapper {
public:
FooWrapper(Foo* foo, FooWrappersMutex* mutex);
/* Wrapped functions from Foo */
};
Internally, FooWrapper wraps calls to the Foo functions with the shared mutex.
I want to test FooWrapper for thread safety. My biggest problem is the fact that threads are managed by the operating system, which means I've got less control on their execution. What I would like to test is the following scenario:
Thread 1 calls fooWrapper1->someFunc() and blocks while inside the function
Thread 2 calls fooWrapper2->anotherFunc() and returns immediately (since someFunc() is still executing)
Thread 1 finishes the execution
What is the simplest to test a scenario like this automatically?
I'm using QT on Win32, although I would prefer a solution which is at least cross-platform as QT is.
You might want to check out CHESS: A Systematic Testing Tool for Concurrent Software by Microsoft Research. It is a testing framework for multithreaded programs (both .NET and native code).
If I understood that correctly, it replaces the operating system's threading libraries with its own, so that it can control thread switching. Then it analyzes the program to figure out every possible way that the execution streams of the threads can interleave and it re-runs the test suite for every possible interleaving.
Instead of just checking that a particular thread is finished or not, why not create a fake Foo to be invoked by your wrapper in which the functions record the time at which they were actually started/completed. Then your yield thread need only wait long enough to be able to distinguish the difference between the recorded times. In your test you can assert that another_func's start time is after some_func's start time and it's completed time is before some_funcs completed time. Since your fake class is only recording the times, this should be sufficient to guarantee that the wrapper class is working properly.
EDIT: You know, of course, that what your Foo object does could be an anti-pattern, namely Sequential Coupling. Depending what it does, you may be able to handle it by simply having the second method do nothing if the first method has not yet been called. Using the example from the Sequential Coupling link, this would be similar to having the car do nothing when the accelerator pedal is pressed, if the car has not yet been started. If doing nothing is not appropriate, you could either wait and try again later, initiate the "start sequence" in the current thread, or handle it as an error. All of these things could be enforced by your wrapper as well and would probably be easier to test.
You also may need to be careful to make sure that the same method doesn't get invoked twice in sequence if an intervening call to another method is required.
Intel Threadchecker.
If I recall correctly the tool checks your code for theoretically possible data races.
The point is you don't need to run your code to check whether it's correct or not.
When you start multithreading, your code becomes, by definition, non-deterministic, so testing for thread safety is, in the general case, impossible.
But to your very specific question, if you insert long delays inside Foo to cause each Foo method to take a looonnng time, then you can do what you ask. That is, the probablity of the first thread returning before the second thread enters the call becomes essentially zero.
But what is it that you're really trying to accomplish? What is this test supposed to test? If you trying to validate that the FooWrappersMutex class works correctly, this won't do it.
So far I've written the following code. Sometimes it works and sometimes the test fails, since the Sleep is not enough for running all threads.
//! Give some time to the other threads
static void YieldThread()
{
#ifdef _WIN32
Sleep(10);
#endif //_WIN32
}
class FooWithMutex: public Foo {
public:
QMutex m_mutex;
virtual void someFunc()
{
QMutexLocker(&m_mutex);
}
virtual void anotherFunc()
{
QMutexLocker(&m_mutex);
}
};
class ThreadThatCallsFooFunc1: public QThread {
public:
ThreadThatCallsFooFunc1( FooWrapper& fooWrapper )
: m_fooWrapper(fooWrapper) {}
virtual void run()
{
m_fooWrapper.someFunc();
}
private:
FooWrapper& m_fooWrapper;
};
class ThreadThatCallsFooFunc2: public QThread {
public:
ThreadThatCallsFooFunc2( FooWrapper& fooWrapper )
: m_fooWrapper(fooWrapper) {}
virtual void run()
{
m_fooWrapper.anotherFunc();
}
private:
FooWrapper& m_fooWrapper;
};
TEST(ScriptPluginWrapperTest, CallsFromMultipleThreads)
{
// FooWithMutex inherits the abstract Foo and adds
// mutex lock/unlock on each function.
FooWithMutex fooWithMutex;
FooWrapper fooWrapper( &fooWithMutex );
ThreadThatCallsFooFunc1 thread1(fooWrapper);
ThreadThatCallsFooFunc2 thread2(fooWrapper);
fooWithMutex.m_mutex.lock();
thread1.start(); // Should block
YieldThread();
ASSERT_FALSE( thread1.isFinished() );
thread2.start(); // Should finish immediately
YieldThread();
ASSERT_TRUE( thread2.isFinished() );
fooWithMutex.m_mutex.unlock();
YieldThread();
EXPECT_TRUE( thread1.isFinished() );
}
Jinx to the rescue
http://www.corensic.com/