recursiveness of Glib::Mutex::Lock

[sam tygier <samtygier yahoo co uk>]

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