[Pixman] Making ref counting thread safe

[Siarhei Siamashka]

On Wednesday 05 January 2011 00:04:14 Soeren Sandmann wrote:
> 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.
 
This problem looks bad enough to me, or at least makes me feel uneasy. Changing
how the caching works could also cause some weird problems in the future unless
everything is carefully taken into account. Also various tools like helgrind
will complain a lot and it would be hard to differentiate real problems from
just some mostly safe ugliness.

In addition, requiring not to change the properties may be a bit restrictive,
limiting the usefulness of this model.

I would suggest to generally forbid using the same pixman_image_t from multiple
threads, but also add a function for creating pixman_image_t clone, which
would share the pixel buffer with the original image and track pixel buffer
lifetime via thread-safe refcounting. So using the same image from another 
thread would just require creating a clone instead of doing 'pixman_image_ref', 
all the rest should be exactly the same. I wonder if it can be even done 
implicitly in 'pixman_image_ref' by checking thread id and deciding whether to
create a clone automatically.

> 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.

It might be useful for some operations which are heavy on CPU, such as
gradients or high quality scaling. But for the majority of simple operations 
which are memory bandwidth limited, using multiple threads for rendering has
little sense in my opinion.

-- 
Best regards,
Siarhei Siamashka