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

[Chris Vine <chris cvine freeserve co uk>]

On Mon, 17 Oct 2011 23:40:01 +0100
Chris Gordon-Smith <c gordonsmith gmail com> wrote:
[snip]
> Hmmm. Are you saying that instead of calling Glib::Thread::create, I
> could call the equivalent for std::thread? If feasible, it would be a
> definite improvement over what I am currently doing.

Yes.

There is no magic to threads.  They are threads of execution started by
the kernel (in the case of linux, by the clone() call).  Mutexes and
semaphores are executed in the kernel (in the case of linux by the
futex system calls).  glibc's pthreads implementation calls into these.
glib (on unix-like systems) in turn calls into glibc's pthreads.  gcc's
C11 and C++11's std::thread implementations will probably call into
glibc's pthreads implemention on unix-like systems also, although I
guess it is possible that they might go into glibc directly in other
ways. But they will all use the same kernel primitives

As it happens C11 and C++11 threads require some relaxed memory ordering
options for its atomics that pthread doesn't provide (pthreads and
windows threads provide stricter/safer sequential memory ordering), and
that may require a dip into processor specific assembly code.  But it
almost certainly will be a pthreads based implementation underneath on
unix-like systems so that std::thread::native_handle() can return
something meaningful.

If you are using windows, again I suspect visual studio's implementation
of std::thread calls into windows thread primitives.  But if in doubt,
send them an e-mail.  (Microsoft are pretty responsive on this kind
of thing.)

Chris