[Insight-developers] itkTimeStamp Test Failures Mistery

[Luis Ibanez]

Tom, Brad,

You bring up very good points here.

In the typical use of the Modified time in ITK,
the TimeStamp instance belong to a DataObject
or a ProcessObject.

The TimeStamp has variables that are static
inside the Modified() function, but not static
as globals.

The situation that the test is exercising would
not happen in a typical execution of a filter.

Normally the filter will have its Set() methods
called (hence triggering calls to Modified),
and then its Update() method called, at which
point, if it is a multi-threaded filter, it
will spawn multiple threads.  The filter
itself would not call its Modified() method
during the execution of its own threads.

A typical flow will look like:

    filter->SetParameter1( x );  // Modified()
    filter->SetParameter2( x );  // Modified()
    filter->SetParameter3( x );  // Modified()
    filter->Update();            // no modified


So,... it seems that the situation where
TimeStamp::Modified() thread-safety would be
required is only if: from different threads we
may be calling Set() methods on that filter.

This is not an impossible situation, but it is
not the most likely to happen.

I could think of an application that runs its
GUI in a separate thread from the ones used for
running the ITK pipeline, and I can imaging an
impatient user clicking on GUI widgets that will
results in calls to Set() methods in the ITK
filter.

I have difficulty imagining a practical situation
in which from multiple threads we will be making
calls to Set() methods in a filter...

Maybe in a collaborative tool ?...


Can anyone suggests other situations where Modified()
calls will be triggered from different threads ?


     Luis


---------------------
Tom Vercauteren wrote:
> Hey Brad,
> 
> 
>>According to QT, the optimized timestamp is thus reentrant but not
>>thread-safe:
>>http://doc.trolltech.com/4.4/threads.html#reentrancy-and-thread-safety
>>"By extension, a class is said to be reentrant if each and every one
>>of its functions can be called simultaneously by multiple threads on
>>different instances of the class. Similarly, the class is said to be
>>thread-safe if the functions can be called by different threads on the
>>same instance."
>>
>>It appears the goal here is to make itkTimeStamp thread-safe. Does any of
>>ITK meet this definition? I know there are some parts which should be
>>reentrant (itkObjectFactory) but are not.
>>Why are we trying to get it to be thread-safe? Is this need? Where is this
>>need? Does every instance of TimeStamp need to meet this requirement?
>>If only some do, do we need two types of TimeStamp class say:
>>itkTimeStamp - guaranteed to be only reentrant.
> 
> 
> I definitely agree that these are the questions we need to answer.
> 
> 
> 
>>itkThreadSafeTimeStamp - guaranteed to be thread-safe as per the above
>>definition
>>I just wanted to check to see why this test was written the way it was and
>>if it was intentionally done so.
> 
> 
> Well I wrote that test :(
> I just used the simplest framework I could think of at that time to
> test the timestamp. Guess it wasn't that easy...
> 
> Tom
>