Thread safety?

[RivieraKid]

Hi,

I'm playing with ptex library and I'm wonder that ptex seems not to be
thread safe.

My test program crashes when PTexFilter::eval (probably getPixel) is
not explicitly protected when using from multiple threads.
Platform: win64 - VS2008

A part of my code (based on ftest.cpp from ptex/tests directory)

#pragma omp parallel for
for (int iv = 0; iv <= 1024; ++iv)
{
for (u = 0; u <= 1; u += .0125)
{
float v = iv / 1024.0f;
float result[4];
#pragma omp critical
{
f->eval(result, 0, 1, faceid, u, v, uw, 0, 0, vw); // CRASH when
not in critical section !!!
}
//printf("%8f %8f -> %8f\n", u, v, result[0]);
}
}

Thanks for help.
Martin

[brentb]

On Oct 4, 2:42 am, RivieraKid <dus...@gmail.com> wrote:
> I'm playing with ptex library and I'm wonder that ptex seems not to be
> thread safe.
>
> My test program crashes when PTexFilter::eval (probably getPixel) is
> not explicitly protected when using from multiple threads.

Ptex is thread-safe but you need to make a separate PtexFilter
instance per thread. I should probably clarify this in the docs.

Btw, constructing a filter instance is very cheap. We just construct
a thread-local filter each time we need it which in prman is per
texture call per shading grid (batch of about 256 shading samples).
The filters are applied to textures which come from a global cache.

[Martin Dušek]

Thanks again for reply! It's nice to share prman's implementation details :o)

Regards
Martin

2010/10/4 brentb <brent....@disney.com>:

[brentb]

On Oct 4, 1:02 pm, Martin Dušek <dus...@gmail.com> wrote:
> Thanks again for reply! It's nice to share prman's implementation details :o)

I should clarify and add a disclaimer. In our (Disney Animation
Studio's) custom ptex shadeop for prman we construct a local filter
instance on each shading grid. I can't comment on what prman's
builtin ptexture shadeop does as that is proprietary to Pixar.

[Lixuan Zhu]

What about Ptexture::open and Ptexture::getData. 

May I call them in different threads?

For example: one thread open a PTex file and share the PtexPtr<PtexTexture> with other threads.

Other threads just read and write to the Ptexture concurrently.

Best regards,

Tyler

[Brent Burley]

Ptexture::open and getData are both concurrent.  Filtering is also concurrent but you need a separate PtexFilter per thread.  If you have heavy contention though you may want to have multiple caches because the locking overhead can become significant in the current implementation (though threading performance is being addressed with future development).  To your specific questions, 

Note that Ptexture is read only.  PtexWriter is non-concurrent.

[Lixuan Zhu]

Thanks, it helps a lot.

I am reading PtexCache's implementation. There are two locks used: openlock and cache lock.

Openlock is used to guard "search path" and cache lock is used to guard internal data structure for cached textures(files).

I wonder why you use Spin lock for cache lock and mutex for open lock? Is there some tradeoff?

Also is it possible to try some better data strutter to maintain cached textures? (like Read-Copy-Update method)

Best regards,

Tyler

[Brent Burley]

Mutex is used for locks that might wait an significant or indefinite amount of time.  For short waits, spinlock provides much lower overhead.

I'm in the process of rewriting the cache to be mostly lock free, at least for reading items that are in cache.  This seems to be the most efficient way to manage a shared cache on current architectures.

--

---
You received this message because you are subscribed to the Google Groups "ptex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ptex+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lixuan Zhu]

Thanks!!

Is the dev code of the new PTEXCache available in Ptex GitHub? 

The current linked list based HashDict using char* as key is already much faster than standard C++ HashMap. 

Do you plan to implement the HashDict using atomic instructions(e.g., Compare-and-swap )? 

Arguably, the reading the hash map structure might take advantage of reading is more frequent than updates? Also the memory access pattern of this data structure might cause Cause Cache Line Bouncing?

Best regards,

Tyler

[Lixuan Zhu]

Not sure if it is useful, I also know SpinLock will also cause cache line bouncing problem on ManyCores:

The lock variable is set by the test_and_set operation on every spinning cycle. While CPU 1 is in the critical section, CPU 2 and 3 constantly read and write to the cache line containing the lock variable. The line is constantly transferred from one cache to the other, because both CPUs must acquire an exclusive copy of the line when they test-and-set the lock variable again. This is called "cache line bouncing", and it imposes a big load on the memory bus. The impact on performance would be even worse if the data protected by the lock was also lying in the same cache line 

Best regards,

Tyler 

[Brent Burley]

My new hash map is completely lock free for read.  For the spinlock, I only attempt the lock if it appears to be unlocked, so I think this should minimize the cache line thrashing you describe.

E.g.

    Entry* lockEntries()

    {

        while (1) {

            Entry* entries = _entries;

            if (entries && AtomicCompareAndSwapPtr(&_entries, entries, (Entry*)0)) {

                return entries;

            }

        }

    }

My dev branch is not yet public.  I will push it as soon as it is feature complete.