Make bvhutil safe for multi-threaded usage
authorSergey Sharybin <sergey.vfx@gmail.com>
Fri, 10 Jan 2014 11:21:39 +0000 (17:21 +0600)
committerSergey Sharybin <sergey.vfx@gmail.com>
Mon, 13 Jan 2014 09:57:52 +0000 (15:57 +0600)
commit881fb4387883e751e333836a50da2ec6dcc23afb
treed48295632b8741fbcf4f3027ffd26730ee86a04e
parentbc989497deeaf2ec79ccfbe7b5e43509eb867b06
Make bvhutil safe for multi-threaded usage

There were couple of reasons why it wasn't safe for usage from
multiple threads.

First of all, it was trying to cache BVH in derived mesh, which
wasn't safe because multiple threads might have requested BVH
tree and simultaneous reading and writing to the cache became a
big headache.

Solved this with RW lock so now access to BVH cache is safe.

Another issue is causes by the fact that it's not guaranteed
DM to have vert/edge/face arrays pre-allocated and when one
was calling functions like getVertDataArray() array could
have been allocated and marked as temporary. This is REALLY
bad, because NO ONE is ever allowed to modify data which
doesn't belong to him. This lead to situations when multiple
threads were using BVH tree and they run into race condition
with this temporary allocated arrays.

Now bvhtree owns allocated arrays and keeps track of them, so
no race condition happens with temporary data stored in the
derived mesh. This solved threading issues and likely wouldn't
introduce noticeable slowdown. Even when DM was keeping track
of this arrays, they were re-allocated on every BVH creation
anyway, because those arrays were temporary and were freed
with dm->release() call.

We might re-consider this a bit and make it so BVH trees are
allocated when DM itself is being allocated based on the DAG
layout, but that i'd consider an optimization and not something
we need to do 1st priority.

Fixes crash happening with 05_4g_track.blend from Mango after
the threaded object update landed to master.
source/blender/blenkernel/BKE_bvhutils.h
source/blender/blenkernel/intern/bvhutils.c