<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 12, 2015 at 3:56 AM, Dr. Roman Grothausmann <span dir="ltr"><<a href="mailto:grothausmann.roman@mh-hannover.de" target="_blank">grothausmann.roman@mh-hannover.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear mailing list members,<br>
<br>
Since I already started to create and use a modified version of vtkGaussianSplatter I now wonder if it were possible to make vtkGaussianSplatter run multi-threaded. I'd expect that this is possible if getting and setting pixel values is thread-safe. In vtkGaussianSplatter pixel values are stored in a vtkDoubleArray and read with GetValue and written with SetTuple. There is no info in the docs whether SetTuple (in the way used) is thread-safe. Although GetValue seems to exist, I cannot find any hint in the docs that vtkDoubleArray offers this function, however a thread-safe version of GetTuple exists.<br>
So is there any reason vtkGaussianSplatter cannot be made multi-threaded with VTK6?<br></blockquote><div><br></div><div>The SetTuple/GetTuple methods don't lock the array, so they equivalent to (but slower than) raw memory reads and writes. And writing memory is not thread safe if threads can write to the same memory address or (depending on alignment) to adjacent addresses. </div><div><br></div><div>For vtkGaussianSplatter, any performance gains that could be had by multi-threading would depend on the threads all being able to write at the same time, therefore any sort of "lock" would kill the performance by essentially serializing the writes. Hence, in order for vtkGaussianSplatter to be properly multi-threaded, each thread must write to its own block of output memory. After the splatting is done these must be composited together.</div><div><br></div><div>I wrote a multi-threaded splatting filter once (for ultrasound reconstruction), and in that case I divided my input points such that each thread would write to different (but adjacent) memory regions within the output. It performed well but wasn't completely thread-safe, because it was possible for memory collisions to occur on the border between the regions.</div><div><br></div><div>In summary: properly multi-threading vtkGaussianSplatter would be a moderately difficult task. I haven't heard of anyone who has done it yet.</div><div><br></div><div> - David</div></div></div></div>