Thanks for posting the videos, here is some constructive criticism:
1. First of all; the way you are using the mutex in your code is wrong. You are creating the QMutex with a local scope. The idea is to guarantee exclusive access between threads -- in your example each thread would just lock its own mutex, it's not mutual at all. What you should do is to declare the mutex as a class member. Besides, defining 'Stop' as a public member is probably not a good idea either.
2. In your explanation, you seem to confuse deadlocks with race conditions. A race condition can happen when multiple threads access and manipulate some sort of shared resource concurrently. If an operation is not atomic, it can be interrupted in mid-operation; this can lead to undefined behaviour or even the program to crash. Mutual exclusion is therefore necessary to enforce atomicity for a specific code segment.
A deadlock typically happens when two threads find themselves waiting for each other to release a lock.
3. Most of the time, it is not necessary to subclass QThread, this article has some interesting points: http://labs.qt.nokia.com/2010/06/17/...oing-it-wrong/
There are also many ways to avoid dealing directly with locking primitives altogether in Qt thanks to the QtConcurrent API and by using signals and slots.The only valid reasons I can think of for subclassing QThread is to add functionality that QThread doesn’t have, e.g. perhaps providing a pointer to memory to use as the thread’s stack, or possibly adding real-time interfaces/support. Code to download a file, or to query a database, or to do any other kind of processing should not be added to a subclass of QThread; it should be encapsulated in an object of it’s own.
Bookmarks