Re: mutex problems on Windows

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 08 Jul 2009 01:52:42 -0700
Terrence Cole <terrence zettabytestorage com> wrote:
> 
> On Wed, 2009-07-08 at 07:42 +0300, Dov Grobgeld wrote:
> > That indeed is a more elegant solution! I really feel that I'm
> > learning one step at a time... Regarding the use of
> > g_atomic_int_..., I'm curious how you fit his into the flow?
> > Obviously T and G must be initialized to share a stopping variable
> > s. Who should create this variable? I would be interested to see
> > how you would amend your 1-direction solution so that it also
> > supports stopping.
> 
> A common pattern for simple background tasks that spit out a lot of
> intermidiate data (with most of the tedious init, casting, cleanup,
> error detection, and being compilable missing) could look something
> like this:
[snip]

If the GAsyncQueue object is used only for passing data to an idle
handler, you can in fact dispense with the queue and pass the data as
the data argument of g_idle_add()/g_idle_add_full().  This is because
the main loop is thread safe and locks and unlocks a mutex when the idle
handler and its data is passed to the main loop's own queue object, and
when again it is popped off for dispatch.  As there will have been a
release operation on the main loop's mutex after the handler is loaded
into the main loop and an acquire operation on the same synchronization
object when it is popped off for dispatch, memory visibility between
threads will be guaranteed.

As in the case of your GAsyncQueue example, you will need to allocate
the data on the heap and free it in the idle handler when finished with.

Chris