As of glibmm 2.47 (currently unstable), we have deprecated the glibmm threads API, which wrapped the glib threads API. That’s because C++11 finally has its own standard threading API, and in C++14 its complete enough to replace all of Glib::Threads.

Here’s what replaces what:

• Glib::Threads::Thread: Use std::thread.
• Glib::Threads::Mutex: Use std::mutex.
• Glib::Threads::RecMutex: Use std::recursive_mutex.
• Glib::Threads::Lock: Use std::lock_guard or std::unique_lock.
• Glib::Threads::RWLock: Use std::lock_guard or std::unique_lock.with std::shared_timed_mutex, available in C+14.
• Glib::Threads::Cond: Use std::condition_variable.
• Glib::Threads::Private: Use the thread_local keyword.
• Glib::ThreadPool: I suspect that std::async() solves much the same problems, but I guess you might sometimes need to implement your own thread pool. This seems to be an ongoing discussion among C++ developers.

We’ve replaced use of Glib::Threads in our example code and tests, such as the example in our multithreading chapter in the gtkmm book.

This is quite a relief because we never wanted to be in the concurrency API business anyway, and having a standard C++ concurrency API makes it far easier to write cross-platform code. Now if we could just have a standard C++ network IO API and maybe a file structure API, that would be nice.