Re: mutex problems on Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 08 Jul 2009 01:52:42 -0700
Terrence Cole <terrence@xxxxxxxxxxxxxxxxxxxx> 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
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux