Multi-threaded programs

The constraints
glibmm provides the normal set of thread launching functions, mutexes, condition variables and scoped locking classes required for writing multi-threaded programs using C++.
However, care is required when writing programs based on gtkmm using multiple threads of execution, arising from the fact that libsigc++, and in particular sigc::trackable, are not thread-safe. That's because none of the complex interactions that occur behind the scenes when using libsigc++ are protected by a mutex or other means of synchronization. [1]
[1] These interactions arise from the fact that, amongst other things, a class inheriting from sigc::trackable will, via that inheritance, have a std::list object keeping track of slots created by calls to sigc::mem_fun() representing any of its non-static methods (more particularly it keeps a list of callbacks which will null the connected slots on its destruction). Each sigc::slot object also keeps, via sigc::slot_rep, its own sigc::trackable object to track any sigc::connection objects which it needs to inform about its demise, and also has a function to deregister itself from any sigc::trackable on disconnection or destruction. sigc::signal objects also keep lists of slots, which will be updated by a call to their connect() method or calls to any sigc::connection object relating to such a connection.

The rules
This requires a number of rules to be observed when writing multi-threaded programs using gtkmm. These are set out below, but one point to note is that extra care is required when deriving classes from sigc::trackable, because the effects are unintuitive (see particularly points 4 and 5 below).
Use Glib::Dispatcher to invoke gtkmm functions from worker threads (this is dealt with in more detail in the next section).
A sigc::signal object should be regarded as owned by the thread which created it. Only that thread should connect a sigc::slot object to the signal object, and only that thread should emit() or call operator()() on the signal, or null any connected sigc::slot object. It follows (amongst other things) that any signal object provided by a gtkmm widget should only be operated on in the main GUI thread and any object deriving from sigc::trackable having its non-static methods referenced by slots connected to the signal object should only be destroyed in that thread.
Any sigc::connection object should be regarded as owned by the thread in which the method returning the sigc::connection object was called. Only that thread should call sigc::connection methods on the object.
A sigc::slot object created by a call to sigc::mem_fun() which references a method of a class deriving from sigc::trackable should never be copied to another thread, nor destroyed by a different thread than the one which created it. (One consequence of this is that Glib::Threads::Thread::create() should not be called with a slot argument created by a call to sigc::mem_fun() which represents a method of such a class. It is however safe to pass Glib::Threads::Thread::create() a function object representing such a method by using, say, boost::bind() or, in C++11, std::bind() or a C++11 lambda expression.)
If a particular class object derives from sigc::trackable, only one thread should create sigc::slot objects representing any of the class's non-static methods by calling sigc::mem_fun(). The first thread to create such a slot should be regarded as owning the relevant object for the purpose of creating further slots referencing any of its non-static methods using that function, or nulling those slots by disconnecting them or destroying the trackable object.
Although glib is itself thread-safe, any glibmm wrappers which use libsigc++ will not be. So for example, only the thread in which a main loop runs should call Glib::SignalIdle::connect(), Glib::SignalIO::connect(), Glib::SignalTimeout::connect(), Glib::SignalTimeout::connect_seconds for that main loop, or manipulate any sigc::connection object returned by them.
The connect*_once() variants, Glib::SignalIdle::connect_once(), Glib::SignalTimeout::connect_once(), Glib::SignalTimeout::connect_seconds_once(), are thread-safe for any case where the slot is not created by a call to sigc::mem_fun() which represents a method of a class deriving from sigc::trackable. This is similar to Glib::Threads::Thread::create() as mentioned in point 4.

Using Glib::Dispatcher
The slots connected to sigc::signal objects execute in the thread which calls emit() or operator()() on the signal. Glib::Dispatcher does not behave this way: instead its connected slots execute in the thread in which the Glib::Dispatcher object was constructed (which must have a glib main loop). If a Glib::Dispatcher object is constructed in the main GUI thread (which will therefore be the receiver thread), any worker thread can emit on it and have the connected slots safely execute gtkmm functions.
Some thread safety rules on the use of Glib::Dispatcher still apply. As mentioned, a Glib::Dispatcher object must be constructed in the receiver thread (the thread in whose main loop it will execute its connected slots). By default this is the main program thread, although there is a Glib::Dispatcher constructor which can take the Glib::MainContext object of any thread which has a main loop. Only the receiver thread should call connect() on the Glib::Dispatcher object, or manipulate any related sigc::connection object, unless additional synchronization is employed. However, any worker thread can safely emit on the Glib::Dispatcher object without any locking once the receiver thread has connected the slots, provided that it is constructed before the worker thread is started (if it is constructed after the thread has started, additional synchronization will normally be required to ensure visibility).
Aside from the fact that connected slots always execute in the receiver thread, Glib::Dispatcher objects are similar to sigc::signal<void> objects. They therefore cannot pass unbound arguments nor return a value. The best way to pass unbound arguments is with a thread-safe (asynchronous) queue. At the time of writing glibmm does not have one, although most people writing multi-threaded code will have one available to them (they are relatively easy to write although there are subtleties in combining thread safety with strong exception safety).
A Glib::Dispatcher object can be emitted on by the receiver thread as well as by a worker thread, although this should be done within reasonable bounds. On unix-like systems Glib::Dispatcher objects share a single common pipe, which could in theory at least fill up on a very heavily loaded system running a program with a very large number of Dispatcher objects in use. Were the pipe to fill up before the receiver thread's main loop has had an opportunity to read from it to empty it, and the receiver thread attempt to emit and so write to it when it is in that condition, the receiver thread would block on the write, so deadlocking. Where the receiver thread is to emit, a normal sigc::signal<void> object could of course be used instead.

Example
This is an example program with two threads, one GUI thread, like in all gtkmm programs, and one worker thread. The worker thread is created when you press the Start work button. It is deleted when the work is finished, when you press the Stop work button, or when you press the Quit button.
A Glib::Dispatcher is used for sending notifications from the worker thread to the GUI thread. The ExampleWorker class contains data which is accessed by both threads. This data is protected by a Glib::Threads::Mutex. Only the GUI thread updates the GUI.

Multi-Threaded Program
Source Code