On Mon, 6 Jul 2009 17:13:07 +0300 Dov Grobgeld <dov.grobgeld@xxxxxxxxx> 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
