[Pixman] [PATCH 2/2] test: Add new thread-test program

Siarhei Siamashka siarhei.siamashka at gmail.com
Wed Oct 9 08:46:46 PDT 2013


On Wed, 09 Oct 2013 17:27:16 +0200
sandmann at cs.au.dk (Søren Sandmann) wrote:

> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> 
> > On Wed, 09 Oct 2013 17:06:06 +0200
> > sandmann at cs.au.dk (Søren Sandmann) wrote:
> >
> >> Andrea Canciani <ranma42 at gmail.com> writes:
> >> 
> >> > Sorry, I didn't realize it beforehand, but I just noticed that thread-test
> >> > fails on MacOS.
> >> > This happens because it relies on the availability of OpenMP to have a
> >> > thread-local state for the prng.
> >> > Would it be ok to have each thread explicitly keep the state of its prng or
> >> > is this another element that the test is supposed to be checking?
> >> 
> >> It's not intended to test the thread-private-ness of the prng states, so
> >> yes, the simplest fix seems to be to just explicitly keep a prng_t
> >> for each thread.
> >
> > Would it really help to pass the test? The fast path cache is using the
> > thread-local storage too.
> 
> But the fast path cache is using the PIXMAN_DEFINE_THREAD_LOCAL macro
> that uses pthread_setspecific() on Mac OS. I suppose it would make sense
> to use that macro in thread_test as well, just to make sure it works.

OK, this is a bit messy. The prng code is only compatible with OpenMP
threads while the thread-test is using pthreads. It also fails with
clang in Linux.

Explicitly keeping a prng_t for each thread would be indeed a good
solution. It also very likely is going to have a lower overhead.

-- 
Best regards,
Siarhei Siamashka


More information about the Pixman mailing list