[Pixman] Making ref counting thread safe
siarhei.siamashka at gmail.com
Mon Jan 3 06:55:21 PST 2011
On Thursday 23 December 2010 23:00:54 Christian Hergert wrote:
> Hi Folks,
> I've been using cairo to do some threaded rendering using an image surface.
> After the rendering completes, it is pushed to an Xlib surface via the Gtk+
> main loop. However, being that pixman_image_ref() and pixman_image_unref()
> use ++ and -- to increment and decrement ref counts, occasionally I get a
> double free in libc. Obviously, this only occurs under the scenario of many
> concurrent renderings.
An interesting question is whether atomic refcounting is the only fix required
or it is just the tip of the iceberg?
How the multithreaded rendering is supposed to be done with cairo/pixman? I can
imagine several scenarios:
a) Some set of images or icons is used from multiple threads, it would be
just a waste of RAM to require each thread to have its own copy of all the
b) The destination image is split into a number of slices so that they can be
rendered by different CPU cores in order to improve performance
c) One thread is doing rendering (repeatedly drawing some image for example),
and another thread is poking it periodically at any arbitrary moments to change
transformation matrix, filter, repeat type or anything else.
For the cases (a) and (b), I would say it really makes a lot of sense sharing
at least pixel buffers, and maybe some immutable image information (like image
format, width, height, stride, ...). But I'm not so sure about the
pixman_image_t structure itself.
And the case (c) is in my opinion a real recipe for a performance disaster, due
to having the need to infest a significant part of code with atomic operations
and thread synchronization primitives (gstreamer works this way).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Pixman