CODEWITHSUNDEEP
c++multithreadingglibgtkmm
jaho
jaho

Reputation: 5002

C++ Gtk threading. Am I doing it right?

I have a gtkmm application and I'm trying to put some long running tasks into separate threads so they don't lock the GUI. Here's a tutorial I've based my design on:

http://www.velvetcache.org/2008/09/30/gtkmmglibmm-thread-example

I use Glib::Dispatcher signals to notify the GUI thread when the work is done or something needs to be updated, however I'm not sure how to pass the data between the worker thread and GUI thread. So far I've been passing a pointer to the class which creates the worker to the worker and then modifying public members of the class, but something tells me it's not the most correct to do it. Here's an example:

class Some_GUI_class
{
public:
    std::string thread_message;

private:
    Worker_class* worker;

    void start_worker()
    {
        if (worker != NULL) return;

        worker = new Worker_class(this);
        worker->sig_message.connect(sigc::mem_fun(*this, &Some_GUI_class::display_message_from_thread);
        worker.start();
    }        

    void display_message_from_thread()
    {
        some_label->set_text(thread_message);
    }
}

class Worker_class
{
public:
    Worker_class(Some_GUI_class* gui_class) : gui_class(gui_class)
    {}

    void start()
    {
        thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker_class::run), true);
    }

    Glib::Dispather sig_message;

protected:
    Glib::Thread* thread;
    Glib::Mutex mutex;

    Some_GUI_class* gui_class;

    void run()
    {
        // ...
        gui_class->thread_message = "Message from a thread!";
        sig_message();                
    }

}

This essentialy works, but I guess if the GUI thread wanted to modify thread_message at the same time there would be a problem? Is it safe to do it like this then as long as I'm sure the variables are only modified by a single thread or is there a better way?

Upvotes: 2

Views: 3263

Answers (2)

Ilya V. Storozhilov
Ilya V. Storozhilov

Reputation: 1

Generally mutex usage is not enough to achieve the desired behaviour. The same worker thread (or another one if you have it) could want to send another message while first one had not been processed by the main thread yet. That is why in addition to mutex you should use message queue (e.g. object of std::deque<std::string> class) instead of just a std::string Some_GUI_class::thread_message variable to avoid this kind of message loss.

Upvotes: 0

ergosys
ergosys

Reputation: 49029

You have a race condition. Even if your gui thread doesn't modify thread_message, allowing the GUI thread to read it while another thread is modifying it is not going to give you long term happiness. This is because std::string is not itself protected from multiple threads accessing it, and has multiple internal fields. If one thread is in the process of modifying one of its internal fields, while another is reading them, the internal state will not be consistent from the point of view of the second.

You can use a mutex in the GUI class to protect access to the variables which might be accessed by another thread. Lock and unlock the mutex in get/set routines, and use those routines for all other accesses to ensure that only one thread gets to access or modify the variables at one time.

Upvotes: 2

Related Questions