[Pixman] Making ref counting thread safe

[Soeren Sandmann]

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> 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
> same stuff
> 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).

There are really two separate things to consider: The first is which
thread-related guarantees will pixman give? Adding atomic refcounts
would add a new guarantee that multiple threads can do ref/unref
simultaneously without causing double frees. 

I do think we should probably go at least one step further and allow
the same image to be used in a read-only way from multiple
threads. "Read-only" here obviously means not using the image as a
destination, but also not changing any of the properties such as
transformations or filters.

The only real reason, aside from the refcounting, that the read-only
access doesn't work at the moment is that the images contains some
cached information: the flags field and the extended
format. Potentially, strange things could happen if two different
threads try to update those fields at the same time, although I don't
think it's a real problem with the memory models on common
architectures (since presumably the two threads would come to the same
result and the "dirty=FALSE" write would not be visible before earlier
updates). Still, it would be good to get this on a less shaky
foundation.

The other thing to consider is whether pixman itself should do
threaded rendering. I think that will eventually be interesting, but
getting basic thread safety and threading primitives seems to be a
pre-requisite.


Soren