RE: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?

["Gavin Lambert" <gavinl compacsort com>]

Quoth Chris Vine:
> I can't see any reason why using std::mutex to lock data in a thread
> created by Glib::Thread::create() should cause any difficulty.  It
> would be extremely difficult to create such a difficulty, as mutexes
> lie in the kernel. 

Futex-based mutexes lie only half within the kernel; by their very design
they're intended to avoid calling into the kernel as much as possible, and
over the years there have been a few different and not-quite-compatible
implementations on the userspace side.

> As well as being difficult, it would also be completely perverse for 
> the gcc libstdc++ authors to pervert their system calls so as make 
> std::mutex incompatible with gcc's pthread mutex implementation, 
> and equally perverse for the visual studio authors to make 
> std::mutex incompatible with windows critical sections.  Amongst
> other things, it would make it impossible for programs written for
> std::thread to call into native windows or unix-like libraries which
> happen to use their respective native implementations.

While this is true, sometimes perversity is required for other reasons.
Windows critical sections, for example, don't support a "lock with timeout"
operation, and might require some hoop-jumping to implement atomic
release-lock-and-check-condition operations (since "condition variables"
aren't natively supported).  And in the past I've had to invent my own mutex
implementation in order to support priority inheritance, for example.

Having said all this, the C++11 mutexes and other threading constructs are
almost certainly going to get copied verbatim out of the boost library
(since that's what inspired them), so anyone worried about how they're going
to behave can probably just look at those. :)