Re: mutex problems on Windows
- From: Dov Grobgeld <dov grobgeld gmail com>
- To: Chris Vine <chris cvine freeserve co uk>
- Cc: Gnome List <gtk-list gnome org>
- Subject: Re: mutex problems on Windows
- Date: Tue, 7 Jul 2009 10:56:46 +0300
Thanks a lot for the help.! I have now solved the problem by
introducing a GCond,called C below, into the flow. For posterity, here
is the modified flow, which is actually a general model of a
client-server interaction between a worker thread and the gui thread.
* W locks j->M through g_mutex_lock(j->M) so that G will not send
the condition signal until we are ready for it.
* W fills in j with various info to display.
* W calls g_idle_add(GSourceFunc(cb_update_job), j) to indicate to
G that there is info to display.
* W waits on C through g_cond_wait(j->C, j->M). This will unblock
j->M and allow G to continue.
* G is called in cb_update_job().
* G updates the gui, also possibly updates j based on GUI interaction.
* G does g_mutex_lock(j->M) which causes it to wait until W has
reached g_cond_wait().
* G sends a condition signal through g_cond_signal(j->C)
* G does g_mutex_unlock(j->M). This will allow W to take the lock
in g_cond_wait().
* W wakes up and does a g_mutex_unlock(j->M) as it no longer needs
the lock on the mutex.
* W examines the return info that G filled in into j and contiues
or aborts its operation.
Quite complex I have to admit. Is there a simpler way to solve the
same problem (query/response)?
Regards,
Dov
2009/7/7 Chris Vine <chris cvine freeserve co uk>
>
> On Mon, 6 Jul 2009 17:13:07 +0300
> Dov Grobgeld <dov grobgeld gmail com> wrote:
>
> > I'm having a problem with GMutex under Windows that don't lock. The
> > behaviour is definitely different from that under Linux.
> >
> > The system is composed of to threads. A gui thread G and a worker
> > thread W. The ping pong between the threads via a mutex j->M should
> > work as follows. j is a job data structure that carries info between
> > the worker thread and the gui thread.
> >
> > 1. W locks j->M through g_mutex_lock(j->M) so that a subsequent
> > lock will block.
> > 2. W fills in j with various info to display.
> > 3. W calls g_idle_add(GSourceFunc(cb_update_job), j) to indicate
> > to G that there is info to display.
> > 4. W blocks on M through a second call to g_mutex_lock(j->M)
> > 5. G is called in cb_update_job() and updates the gui, also
> > possibly updates j, and then does g_mutex_unlock(j->M)
> > 6. W wakes up and does a g_mutex_unlock(j->M) as it no longer
> > needs the lock on the mutex.
> > 7. W examines the return info that G filled in into j and contiues
> > or aborts its operation.
> >
> > The problem on Win32 is that g_mutex_lock in 4 doesn't block and the
> > thread continues, which eventually will cause the system to crash.
> >
> > Is something supposed to be different under Windows, or should I file
> > a bug?
>
> This won't work. Mutexes have ownership once locked. An unlock
> operation on a mutex must be carried out by the same thread that locked
> it.
>
> You could use condition variables to achieve what you want. It would
> also be wise to read up a little more on threading, and in particular
> pthreads (which GThreads mimic).
>
> Chris
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]