Quoth Chris Vine: > 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
There will be some caveats; despite using the same kernel primitives they might not be using the same glibc elements, or may tack on additional data. As such, you probably won't be able to convert a std:: mutex into a Glib:: mutex, although in principle there shouldn't be any problem in using a std:: mutex to wake up a Glib:: thread, or vice versa. (This may depend on the specific implementation of the library you use.) It's also possible that one or the other have particular per-thread init or cleanup requirements which won't be met by the other (I recall the Win32 days when the CRT got grumpy if you used CreateThread instead of _beginthread, and MFC got grumpy if you used either instead of AfxBeginThread); I'm not really familiar enough with either threading model to say definitively whether this will or won't be an issue here. _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
