QT video tutorials on YouTube

**rootshell** · 30th January 2011, 01:30

Hello all,

I have also posted this at the offical QT developer forums...

While in the process of learning QT, I have been creating YouTube videos as a way to give back to the community that has taught me so much.

http://www.youtube.com/user/VoidRealms

PLease let me know if you have any feedback!

**tbscope** · 30th January 2011, 04:54

I've watched a couple of videos and they are pretty good.
In fact, they are better than most of the eLearning videos of Nokia. Yesterday I sent a comment to Nokia that they should use native english speakers or at least put subtitles on their videos because the audio is bad and the speakers are hard to understand.

You seem to be a native english speaker? Your videos are much more comfortable to listen to.

Now some comments on the videos explaining QThread.
I don't know if you know this, but the QThread object uses the main event loop.
In part 4, you got away by not using slots :-)
Signals usually are not the problem, but slots in another thread are. You must have an event loop running in your thread. And you must make sure that the slot code is executed inside the thread. Otherwise strange problems occur. Recently, someone here on this forum created a multi threaded client/server application and got synchronization problems. It turned out that a slot was defined as a member of the QThread subclass itself. When this slots is being called from within the main event loop, the code in the slot is being run inside the main thread.

One of the correct ways to solve this is to subclass a QObject, put all the code you want to run in the thread (including signals and slots) inside that QObject subclass.
In the main thread (in your main dialog or window for example) create an object based on this QObject subclass.
Create also a QThread object (don't subclass it).
Connect all your signals and slots.
Move the QObject based object to the QThread object and start the thread.

Example: http://www.kdedevelopers.org/node/4377

Well, this comment is just because I think that part 4 of the QThread tutorial will (involuntary) want people to add a slot like you've added the signal. 90% of the time it'll work and no problems will be seen. But afterwards that's a real nightmare to debug.

**helloworld** · 30th January 2011, 11:56

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.