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/

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.
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.