On Mon, 17 Oct 2011 23:40:01 +0100 Chris Gordon-Smith <[email protected]> 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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
