Re: Glib mutex doesn't work on Windows

["John K. Luebs" <jkluebs luebsphoto com>]

Michael T. wrote:
> Hi,
>  I'm using glib mutexes on Windows and I think they don't work.
> I tried to use WIN API mutexes instead and they did work.
>
> Short sample program:
> I initialize the WIN API mutex, then create two threads using WIN API with this simple code:
>
> DWORD WINAPI MyThreadFunction( LPVOID lpParam )
> {
>     int i = 0;
>     for(i=0; i<30; i++)
>     {
>         WaitForSingleObject( Mut, INFINITE);
>
>         printf("Jozko jolko %d, thread %d\n", i, GetCurrentThreadId()) ;
>
>         ReleaseMutex(Mut);
>     }
>     return 0;
> }
>
> Without the mutexes the output is messy, because the console is a critical section, and unsynchronized 
> threads create mess. With mutexes applied the output is nice and clean.
> When I try the Glib mutex with the same code, it doesn't work and output remains messy.
>
> The mutex initialization looks like this:
>
> GStaticMutex dataMutex = G_STATIC_MUTEX_INIT;
>
> The function:
>
> DWORD WINAPI MyThreadFunction( LPVOID lpParam )
> {
>   int i = 0;
>
>     for(i=0; i<30; i++)
>     {
>
>         g_static_mutex_lock(&dataMutex);
>
>         printf("Jozko jolko %d, thread %d\n", i, GetCurrentThreadId()) ;
>
>         g_static_mutex_unlock(&dataMutex);
>
>     }
>     return 0;
> }
>
> I used the GStaticMutex according the example code here:
> http://library.gnome.org/devel/glib/2.17/glib-Threads.html#g-static-mutex-lock
>
> There's no problem with compiling, I also don't get any error during execution. I am using MinGW compiler to 
> create the binaries.
> Why does it not work?
>   

Are you sure it doesn't work, though? Are you certain that the 
g_static_mutex isn't working exactly as it should?
What exactly do you mean that the output is "messy"? Is it that the 
characters are actually jumbled up, or that you get more than one printf 
from a given thread in a row and it doesn't alternate back and forth? If 
it is the former, that is odd as the standard, modern MSVCRT printf is 
supposed to be thread-safe to a point similar to POSIX, and even without 
any external locks one would expect that the entire lines submitted to 
printf would remain intact. If it is the latter, that you don't get 
clean alternation of lines, then realize that your locking scheme 
doesn't in any way enforce that, and the Win32 MUTEX version just 
happens to work out that way. Depending on how things are scheduled, 
just because a thread locks and unlocks doesn't guarantee control is 
immediately passed to another waiting thread. This does not indicate 
anything is amiss with the locking. The locks by themselves guarantee 
serialization, they don't guarantee or stipulate progress or fairness, 
though the kernel is designed to act sensibly, more-or-less.

As mentioned, the underlying implementation may be using Win32 
CRITICAL_SECTIONs, which are not equivalent to the kernel mutexes, but 
should give the same serialization guarantees. As someone else 
mentioned, the g_static_mutex may be recursive or not (and if it is 
CRITICAL_SECTION based, it will be recursive). I am not sure if this is 
relevant in your situation, because your snippet doesn't suggest 
recursive usage.

--jkl