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



On Tue, 18 Oct 2011 12:49:43 +1300
"Gavin Lambert" <gavinl compacsort com> wrote:
> 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.

Anyone who tries to "convert" a Glib::Mutex to a std::mutex, or to
terminate a thread with a different call set from the one which created
it, deserves everything they get.

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. 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.

Chris




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]