There are two ways to use QThread, with and without an event loop, and the preferred method for talking to a QThread depends on which of them you use.

Way 1: Without an event loop

When you’re not using an event loop, the thread’s run() method often looks like this:

void MyThread::run()
{
    forever
    {
        // Do some stuff
    }
}

Since this method does not use an event loop, there is no way to deliver a signal to your thread. So if you want to pass data into the thread, you have to use a good old fashioned mutex. Let’s look at an example showing you how to stop your thread:

void MyThread::run()
{
    forever
    {
        {
            // "mutex" and "stopRequested" are member
            // variables of MyThread:
            QMutexLocker locker(&mutex);
            if(stopRequested)
                return;
        }

        // Do some stuff
    }
}

void MyThread::stop()
{
    QMutexLocker locker(&mutex);
    stopRequested = true;
}

In this case, we have to check the stopRequested variable in a timely manner in our thread’s run() method. The longer you run between checks, the longer it will take your thread to actually stop.

Outside observers can use the finished() signal to know when your thread is actually done. So if you are in a QMainWindow, for example, and a closeEvent() happens, you can ignore the event, call MyThread::stop(), and then when the QThread::finished() signal arrives, you can actually close the window.

The downside is that the stop() call will actually block while it tries to acquire the mutex. Given the way this code is written, the blocking will probably be very short, but hey, I hate blocking. Let’s see if we can dig up a better way to do this.

Way 2: With an event loop

If you have an event loop, you can use Qt’s meta-objects to talk to your thread. Let’s look at the same example as before, only this time with no locking or blocking.

void MyThread::MyThread()
{
    moveToThread(this);
}

void MyThread::run()
{
    QTimer *timer = new QTimer();
    connect(timer, SIGNAL(timeout()),
        this, SLOT(doSomething()));
    timer->start(0);

    exec(); // starts the event loop, and doesn't
            // return until it is told to quit()
}

void MyThread::stop()
{
    if(currentThread() != this)
    {
        // The caller is running in a
        // different thread, so use Qt to
        // call stop() later, on our own thread:
        QMetaObject::invokeMethod(this, "stop",
                        Qt::QueuedConnection);
    }
    else
    {
        // Now the call has arrived from our
        // own thread, yay! We can safely
        // shut down our event loop.
        quit();
    }
}

Look mom! No locks! Now we have killed our thread, safely and gracefully. There is no chance of blocking, and we learned something about QMetaObject.

A couple items to note:

• The doSomething() method is left as an exercise for the reader, but be careful about the QTimer interval. I used 0, which means it will be firing almost constantly.
• The stop() method must be a slot in MyThread (and not just a regular method) or else invokeMethod() will return false and not actually re-invoke stop() for you.
• You can pass arguments to your thread this way, but it requires a bit more fun with QMetaObject::invokeMethod().
• You can reduce this whole thing to a magical macro that you could put at the top of your stop() method, saving you from having to write if(currentThread() == this) at the top of every method. Hint: use the __FUNCTION__ macro.
• To run this example code, you’ll need to #include these files: QThread, QTimer, QMetaObject, QMutexLocker, and QMutex
• To call quit(), it may not actually be necessary to be running on the same QThread (it works for me without the QMetaObject), but this will be required when you start passing in data to your thread. Without it, your program could do unpredictable naughty things. I can’t find anything in the docs about whether quit() is thread safe.

I’ve found this QMetaObject approach the most effective and easiest way to pass data to QThreads safely, without blocking and without locks.

Happy threading!

This thing has every feature imaginable, which means it packs a lot of wires:

Here’s a video tour of all its features, which include the following:

• Auto fly-home if control is lost (uses GPS)
• Heads up video display of altitude, heading, and pitch
• RF beacon if the plane is lost
• Auto stabilization using FMA co-pilot
• Data logger providing an audible report of battery life and other stats
• VR goggles for watching the action
• Pan and tilt camera, controllable from the radio
• High-power transmitter (he’s flown a mile away on FPV)

For me, my work calendar and my personal calendar both showed up as nearly the same shade of red. Fail.

Here’s how I fixed it. This only works if you have the following situation:

• iPhone OS 3.0 or newer
• Using Google Calendar with CalDAV (not Exchange)
• Note: I use Exchange for my work calendar and Google for my personal calendar, and I want them both on my iPhone with different colors

Steps to change the color (this takes about 5 minutes if nothing goes wrong).

1. Open iCal on your Mac (don’t have a Mac? Maybe Mozilla Sunbird can do this too)
2. Subscribe to your Google Calendar (instructions to do this
3. In the sidebar, notice your new calendar appears
   
4. Right-click on the new calendar and select Get Info
5. Now change the color to what you want
   
6. Do nothing, and in a couple minutes your iPhone calendar items will have the new color

If you can’t get iCal setup, don’t fret. It does work. Double check your URL you typed to subscribe to your Google Calendar. Don’t forget the “/user” at the end. Follow Google’s instructions (see link above) very closely.

Good luck!

First of all, just because a programming language has functions, that does not mean it is functional. In fact, its confusing name has nothing to do with functions. The history of the term function, as used in the computation world, hails back to the 1930’s when Alonzo Church created Lambda Calculus to be able to use and define mathematical algorithms on paper. Later, when computers arrived on the scene, programmers adopted the term function to describe a chunk of code that could be re-used by other chunks of code. Functions, in this context, have been adopted by every programming language I know of, including assembly language. Functions are commonly referred to as “routines”, “subroutines”, or “procedures”. Some might even argue that a “method” is pragmatically identical to a function.

Here’s where the confusion begins.

This is hard to explain rigorously, but here goes anyway.

Some languages, like C, tend to encourage computer programmers to make use of functions. Programs written in these languages tend to consist of a set of functions, and a “main” function that kicks everything off. Such a language is often referred to as “procedural”, but really the term “procedural” refers to a style of programming, and does not really describe a language, per se. It is most often used as an antonym to the concept of “object oriented”. But, oddly, it has nothing to do with “functional” programming.

Other languages, like Scheme and Haskell, tend to encourage computer programmers to write code with functions that avoid internal state changes and produce no side effects when called. For example, these language discourage global variables, and particularly the calling of functions that would mutate global variables (that would be a side effect).

To sum up.

Procedural programming languages can be functional or not. Functional programming languages can be procedural or not.

Here’s a table:

If you take nothing else away from this article, take this: The C programming language is not a functional language. It’s not bad, it’s just not functional.

1. Hulu in the Living Room

In 2010, Hulu will partner with a company like Western Digital or Popcorn Hour to release a tiny box that connects to your HDTV to watch TV shows and movies, streamed from Hulu’s servers. The box will cost less than $100, and have no monthly subscription, because its development will be subsidized by Hulu’s ad revenues. If it’s not released in 2010, it will at least be announced.

2. Cable Networks Become Record Labels

Just like iTunes changed the music industry, online media and broadband Internet access will start to change the TV industry. It remains to be seen who will be the big player (my money’s on Hulu), but one thing is for sure: Americans will have a choice when it comes to buying subscription TV services. The trend will begin in 2010, allowing consumers to get on-demand TV content for free, and will finish some time in the future with cable companies either totally transforming into something like modern record labels, or going out of business.

3. HDTV Sales Will Boom

HDTV’s have gotten so inexpensive that nearly every American household will have one by the end of 2010. This will be driven by the fact that online media will be so easily accessible that most people won’t need to buy cable, so they can easily justify the cost of a new $500 TV.

4. Qt’s Best Year

Companies who develop desktop application software that needs to run on Mac and Windows will simply have no other choice for their developers than Qt. That trend will strengthen in 2010 to the point that it’s a no-brainer decision over platform-specific choices like .NET, Cocoa, and others. Qt has matured so much over the last 5 years that its toe-hold in this market will grow to a full Nelson in 2010.

5. Model Aviation Takes Off

Model airplanes have gotten very popular and accessible. Manufacturers have pushed prices down so low that anyone can afford to get into the hobby. Batteries, R/C electronics, and planes have gotten cheaper, and planes have gotten easier to fly for the novice pilot. The entry-level model airplane market will take off in 2010.

Your Turn

Do you agree with my predictions, or am I totally off?

Have any predictions of your own?

It happened again tonight, this time compliments of the Time Machine menu bar icon (I know, it’s a curse).

I noticed months ago that the icon spins while Time Machine is backing up my iMac. But that’s not the drool feature. The little hands on the clock spin, but they go backwards! It’s a gentle reminder that Time Machine lets you go back in time to restore your files.

Awesome, but now it’s time for another new keyboard.

• Stryker Fuselage from ParkZone
• A tiny 2-cell LiPo battery
• Two cheap servos
• A cheap voltage converter

I did not put a motor on the Stryker and used a tiny battery. It slopes beautifully in 15-20mph wind. In fact, I had to add some weight to get better penetration.

I highly recommend the Stryker for slope flying.

Screenshot:

Here’s the code:

QProgressBar {
border: 1px solid black;
text-align: top;
padding: 1px;
border-bottom-right-radius: 7px;
border-bottom-left-radius: 7px;
background: QLinearGradient( x1: 0, y1: 0, x2: 1, y2: 0,
stop: 0 #fff,
stop: 0.4999 #eee,
stop: 0.5 #ddd,
stop: 1 #eee );
width: 15px;
}

QProgressBar::chunk {
background: QLinearGradient( x1: 0, y1: 0, x2: 1, y2: 0,
stop: 0 #78d,
stop: 0.4999 #46a,
stop: 0.5 #45a,
stop: 1 #238 );
border-bottom-right-radius: 7px;
border-bottom-left-radius: 7px;
border: 1px solid black;
}

And here’s the .ui file you can open in Designer (right-click that link and choose “Save as…”).

Happy hacking!

To subscribe to the podcast, visit the LDS General Conference Podcast page.

This article won’t go into detail about lock-free algorithms, but instead I will offer a “poor man’s” method for crossing thread boundaries in Qt without using locks (no mutexes, no semaphores). At least, your code won’t have any locks. More on that later.

For years, Qt has sported an easy-to-use threading library, based around a class called QThread. As of Qt4, you can use QThread to start your own event loops. This might sound somewhat uninteresting at first, but it means you can have your own signals and slots outside the main thread. The Trolls created a new way to connect signals to slots such that signals can actually cross thread boundaries. I can now emit a signal in one thread and receive it in a slot in a different thread. This is hugely useful when you want to, for example, integrate a blocking-happy library into your application. Here’s what I’m talking about in pictures:

Signals can arrive at any time from the threads, just like any other signal, and the code in the main event loop doesn’t know anything about multi-threading, locks, or condition variables.

An Example

Let’s say you want to integrate with a third-party library that blocks when you call its functions. Of course, if you call this library from your main event loop, your application will freeze while it’s running. That would be annoying, and you can give your users a better experience than that. Let’s wrap that library in a QThread. First, you need to declare a new QThread subclass, like this:

class MyLibraryWrapper : public QThread
{
Q_OBJECT
public:
    MyLibraryWrapper();
protected:
   void run();
signals:
   void done(const QString &results);
private slots:
   void doTheWork();
};

The run() method is called automagically by Qt when the caller calls start() on your thread. This is similar to how Java’s Thread class works.

The done() signal is how the object tells you it is finished with its work. It emits a QString in this example, but it can emit anything you want (note that if you want to emit non-primitive or non-Qt types, you need to use the Q_DECLARE_METATYPE() macro, which we won’t go into in this article).

The doTheWork() slot is there to actually do the blocking work. It has to be a slot so we can put it to work after our event loop starts up (which you’ll see in a minute).

Now for the implementation of MyLibraryWrapper:

MyLibraryWrapper::MyLibraryWrapper() : QThread()
{
  // We have to do this to make sure our thread has the
  // correct affinity.
  moveToThread(this);

  // This will do nothing until the user calls start().
}

void MyLibraryWrapper::run()
{
  // This schedules the doTheWork() function
  // to run just after our event loop starts up
  QTimer::singleShot(0, this, SLOT(doTheWork()));

  // This starts the event loop. Note that
  // exec() does not return until the
  // event loop is stopped.
  exec();
}

void MyLibraryWrapper::doTheWork()
{
  // Do the heavy-duty blocking stuff here
  // (simulated by a 5 second sleep for
  // this example)
  sleep(5);

  // When you're done, emit the results:
  emit done("First job's finished.");

  // And some more sleeping for fun
  sleep(3)
  emit done("Second job's finished.");

  // ...
}

To actually use this new class, all you have to do is instantiate it in your main event loop and connect it to a slot. Here’s an example. Let’s say you have a QMainWindow called MyMainWindow. This is how you would set it up as a result of a user button click:

void MyMainWindow::on_someButton_clicked()
{
  MyLibraryWrapper *wrapper = new MyLibraryWrapper();

  // This is the magic that tells the wrapper to
  // notify us when it's done. We use a QueuedConnection
  // to make sure Qt delivers the signal in a thread
  // safe manner
  connect(wrapper, SIGNAL(done(QString)),
          this, SLOT(wrapperDone(QString)),
          Qt::QueuedConnection);

  // This kicks off the wrapper's event loop by causing its
  // run() method to be called
  wrapper->start();
}

void MyMainWindow::wrapperDone(const QString &results)
{
  // The wrapper is now done with its long, blocking
  // operation, and we didn't freeze the application.
  // Yay for us!

  qDebug() << "Here are your results:" << results;
}

Conclusion

Notice that none of our code uses a semaphore, condition variable, or mutex? Using QThread makes it super easy to wrap up libraries that need to block the event loop in a way that is transparent to the caller.

I claimed earlier that this code would be “lock free”. I can’t actually claim that is 100% true. I don’t know for sure, but I imagine that Qt’s internal event loop code does indeed use locks to pass signals between event loops. All I know for sure is that this code crosses thread boundaries without any locks.

Stay tuned for another article that shows how you can call setter functions on your threaded objects without any need for locks.