Re: Strange dead lock with g_threads_enter

[Chris Vine <chris cvine freeserve co uk>]

On Sun, 6 Mar 2011 10:57:24 +0800
Wei-Ning Huang <aitjcize gmail com> wrote:
> Thanks Chris. I tried to remove any function call in the
> compile_thread, i.e:
>
> // Thread function
> // It is signaled to wake up for every 1 second
> gpointer motion_compile_thread(gpointer data) {
> ...
>    while (TRUE) {
>      if (!g_mutex_trylock(cp_mutex)) continue;
>      g_cond_wait(compile_cv, cp_mutex);
>      g_mutex_unlock(mutex);
> }
>
> Now that what the thread does is simply wake up every 1 second
> (signaled by the main thread) and go back to sleep.
> It STILL deadlocked!!!
> I tried running this on ubuntu 10.10, and it worked perfectly fine (no
> deadlock)

Well, everything depends on what is in your "...".  When the thread
reacquires the mutex when g_cond_wait() returns or through the trylock,
that may involve itself in a sequence of out-of-order locking with
another thread, if your "..." involves acquiring and holding a
second lock apart from your cp_mutex, or it involves acquiring the gdk
global lock.  (Your while loop could of course also create a livelock,
since it doesnt perform a yield, although I doubt that is your issue
here.)

> I'm starting to think it's the bug of gtk+, or perhaps the kernel?
> btw, I'm using Arch Linux with Kernel 2.6.37(autogroup patched), Gtk+
> 2.22.
>
> SI once suspect that it maybe something to do with the autogroup
> patch I'm using, so I switch to the
> default 2.6.37 kernel. The result is the same.. still deadlocks.
>
> frustrated ... (but glad that this didn't happen on ubuntu)

In theory it could be a bug in glib, gtk+ or the kernel.  If, say, your
motion_compile_thread() function is the only function executed by the
test thread and never acquires any other locks than your test mutex,
and you do not have a livelock, then I think you are right to be worried
about that. Otherwise, it is more likely to be a bug in your code, and
the fact that it works on ubuntu is not particularly indicative of
anything, since this may just be the result of timing differences or
different scheduling policies.

I assume incidentally that you have correctly initialised glib for
threading?

Chris