[Insight-developers] Threading in the FDSH

Brady McCary brady.mccary+ITK at gmail.com
Thu Feb 12 19:38:37 EST 2009


insight-developers,

Currently, the state in threading-aware filters in the FDSH is roughly
as follows:

1. Each thread has it's own data blob (GlobalDataPointer). This is
held by the filter and used (mostly) by the (finite difference)
function.
2. The function can collect/cache values in this blob in a thread-safe
way. This is because computation calls to the function are const.
(Actually the previous sentence is not true because ComputeUpdate is
not const. Is this intended or an oversight?).
3. There is never a point in time when the function can change its own
state by considering values it caches in its blob because there are no
thread-safe calls to the function in which the function is not const.

Probably ComputeUpdate should be const in the interest of
thread-safety. Especially considering this comment in
itkLevelSetFunction.h:

"Caching these values here allows the ComputeUpdate function to be
const and thread safe ..."

I would like store values in the cache during an iteration and then
before the next iteration, give the function a chance to update itself
with values stored in the cache. To accomplish this, I will need a
single-threaded non-const call from the filter to the function with
the global data pointer as an argument. This could be either in
GlobalTimeStep or ReleaseGlobalDataPointer.

Is there a reason why GlobalTimeStep and ReleaseGlobalDataPointer are const?

I would appreciate any comments or suggestions.

Brady


More information about the Insight-developers mailing list