Comments on: Lock Free Multithreading in Qt

By: Dave

Dave — Sun, 20 Jun 2010 03:10:28 +0000

Okay, it turns out that subclassing QThread is not actually necessary:

http://blog.exys.org/entries/2010/QThread_affinity.html

You don’t have to write a run() method. You can just *have* a QThread in your class, and call start() on it. Then, call moveToThread(&thread) rather than moveToThread(this).

Very interesting.

By: Victor Jetten

Victor Jetten — Sun, 21 Feb 2010 16:34:44 +0000

it works now, I had commented out “movetothread(this)”. Sorry for polluting your blog! ;-)

By: Victor Jetten

Victor Jetten — Sun, 21 Feb 2010 16:24:09 +0000

sorry! I did not declare sowit under “private slots:” in the class, still getting the hang of this. However now that it runs it does not show every step in the counter, only the last one. I guess emit is not meant for passing values. I’ll check what qtimer does

By: Dave

Dave — Sun, 21 Feb 2010 16:14:29 +0000

Oh, and a couple more things:

Is your method showit() declared as a “slot”, and not just “public”, like this:

public slots:
showit(int i);

Is the show() signal declared as a signal in your thread class like this:

signals:
show(int i);

Also, do you have Q_OBJECT in your Widget class declaration? (you need Q_OBJECT for any class that has signals or slots). You need Q_OBJECT in your thread class too.

If you add Q_OBJECT, you have to re-run “qmake” by the way.

–Dave

By: Dave

Dave — Sun, 21 Feb 2010 16:11:57 +0000

Victor, do you see any warnings on the command line when you run your app (on Windows, you need to add “CONFIG += console” to your .pro file).

I ask because sometimes if you have a typo in your connect() call with your SIGNAL and SLOT text, you won’t see an error in the compiler, but on the command line, you will see a warning when connect() is called.

Also, what is “W”? This should be your thread, not your widget, right?

Lastly, have you used qDebug()? Very handy. Just #include and then you can add debug output like this:

qDebug() < < "showit called with value" << i;

Let me know.

By: Victor Jetten

Victor Jetten — Sun, 21 Feb 2010 15:58:20 +0000

thanks for helping. Showit is nothing else but:
void mod6::showit(const int i)
{
label->setNum(i);
}
where mod6 is the interface class.
In the original prog the thread is a waterbalance model that can run for several hours and gives a lot of results back to the interface at each loop (values, a graph, digital maps). During the run the interface cannot block because the user may need to do things (zoom in and so on). I was also looking at the mandelbrot example in Qt but I liked your mutex-less example.

By: Dave

Dave — Sun, 21 Feb 2010 15:13:45 +0000

My first question is: are you sure you need a thread? It sounds like a QTimer would suffice. It’s usually better to avoid threads if you can.

My other question is: what does the showit() method look like?

By: Victor Jetten

Victor Jetten — Sun, 21 Feb 2010 08:35:27 +0000

Hi Dave, interesting article. Don’t know if your blog is meant for direct help but here goes.
I am porting an application from borland and a newby to Qt. I can’t get the emit to work. I have a main application with a widget, a button and a label (ui form), the on_button_clicked function declares and starts the thread “W” and each loop in the thread gives a result (an int) that has to be show on the label. so I have in the thread class:
signals:
void show(const int i);
in the widget class
void showit(const int i);

which is linked as:
connect(W, SIGNAL(show(int)),this, SLOT(showit(int)), Qt::QueuedConnection);

When I debug the prog the thread is started and it runs 100 loops, each loop emits the counter to showit. The thread runs but nothing is shown.
thanks.

By: Dave

Dave — Mon, 08 Feb 2010 06:03:09 +0000

Sal, your question prompted me to write another article on how to stop QThreads. Here you go:

http://thesmithfam.org/blog/2010/02/07/talking-to-qt-threads/

I hope that answers your question.

By: Sal

Sal — Sun, 07 Feb 2010 21:09:02 +0000

What if you deal with a thread process that is continuous unless you specifically call it to either pause or stop. One other triggering event is a close event, if thread running, then stop it gracefully?