Thorsten Froehlich <tho### [at] trfde> wrote:
> The solution here is either to only pretrace (single threaded then), order 
> sample insertion (only feasible in a multithreaded pretrace), or come up 
> with some other division of the tree avoiding insertion data race conditions.

  Also note that since the radiosity data tree is probably accessed millions
of times per second (for both reading and writing), mutexing each access would
be prohibitively slow, as mutexes (especially those provided by Boost) are
very inefficient. Mutexes are only feasible for functions which are called
relatively infrequently.

  (If a function would otherwise be very fast, eg. take just a few dozens
of clock cycles, adding a mutex lock to it can make it hundreds of times
slower at worst. If the function in question is called very frequently,
eg. millions of times per second, that can have a catastrophical effect
on performance.)

-- 
                                                          - Warp

Post a reply to this message