Hi,
I am hitting a bug in rawtherapee (
http://code.google.com/p/rawtherapee/issues/detail?id=1675 ) which appears to
stem from a difference between the behaviour of Glib::Mutex::Lock() on linux
and windows. The multithreading was originally written on windows, when it was
tested on linux there were dead locks, to several of the Lock() calls were
commented out. Now I am hitting cases where the threads interacted badly, and
so want to get the locks right on linux.
the code roughly looks like
void a(){
Glib::Mutex::Lock lock(mutex);
do stuff requiring lock;
b();
}
void b(){
#ifdef WIN32
Glib::Mutex::Lock lock(mutex);
#endif
do stuff requiring lock;
}
a and b are both methods that called from out side the class. this apparently
works on windows, but sometimes crashes on linux. It deadlocks on linux if the
ifdefs are removed.
It looks to me like under windows Glib::Mutex::Lock() is recursive, and under
linux they are not.
The GLibmm docs say "Glib::Mutex is not recursive, i.e. a thread will deadlock,
if it already has locked the mutex while calling lock()" however the glib docs
say "GMutex is neither guaranteed to be recursive nor to be non-recursive."
I guess rawtherapee should switch to using RecMutex.
Are the glibmm docs wrong though? is the behaviour the same as glib? Should
glib raise a warning if you try to recursively acquire a Mutex?
Thanks
Sam
_______________________________________________
gtk-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtk-list
