[Insight-users] Cannot abort properlly multithreaded filters

Mon Sep 13 10:47:24 EDT 2004

Thanks for pointing this out.  

We should take a look at both the ProgressReporter and the
ProgressAccumulator
to make sure abort is handled correctly.

I'll put a bug in to the bug tracker and assign it to myself.

As for the Update() vs UpdateLargestPossibleRegion().  The first time
Update()
is called, it sets the RequestedRegion to be the LargestPossibleRegion.  
Subsequent calls to Update() then use the previous setting for the
RequestedRegion.  If you change the input to the pipeline, then you need to 
manage the final RequestedRegion setting.  If you just call Update() again, 
then new input may not be able to handle the request (as you discovered).  
Calling UpdateLargestPossibleRegion() forces the pipeline to redetermine the

regions.  So you can either call UpateLargestPossibleRegion() when you
change
the inputs or change the image resolutions, or you can determine what the
new 
region you want to process is and call

lastFilter->GetOutput()->SetRequestedRegion( regionBasedOnNewInput );
lastFilter->Update();

Jim

-----Original Message-----
From: Didier Rajon [mailto:didier at ufl.edu]
Sent: Sunday, September 12, 2004 9:11 PM
To: Luis Ibanez
Cc: insight-users at itk.org
Subject: Re: [Insight-users] Cannot abort properlly multithreaded
filters

Hi Luis,
Thanks for your answer.
I tried what you suggested but I'm still having the exact same problem.
Since I'm not familiar with the ResetPipeline(), here is a part of my new
code, just to make sure that I call ResetPipeline() at the right moment.

myFunction() // Called after the user changes some parameters on the GUI and
ask for reexecuting a certain task.
  {
   ... // To initialize some stuff.
   myFilter->Set..(); // To update the filter attributes with the user
setting.
   try {
      myFilter->UpdateLargestPossibleRegion();
      }
   catch (itk::ProcessAbort & exc) {
      myFilter->ResetPipeline();
      .... // To free the stuff that has been initialized by myFunction().
      return;
      }
   catch (itk::ExceptionObject & exc) {
      // Here I show the error to the user.
      myFilter->ResetPipeline();
      .... // To free the stuff that has been initialized by myFunction().
      return;
      }
   .... // To pursue the execution of myFunction();
        // To free the stuff that has been initialized by myFunction().
   }

Note that I use UpdateLargestPossibleRegion() instead of Update() to force
itk to recalculate the image extent.  If I use Update(), and because the
first filter of my pipeline resamples the image, I get the error "Requested
region is (at least partially) outside the largest possible region" every
time I change from a small image spacing to a larger one.
Is there something I should be careful with when I use
UpdateLargestPossibleRegion() instead of Update()?

With the above code, my program still has the same behavior than without the
two ResetPipeline().  That is:
    - A segmentation fault happens if I reexecute myFunction() (with new
filter attributes) right after I abort the execution.
    - If I check the status of my process using the "top" command of linux,
I can see that my process is still using 50% of the CPU (on a 2 CPU machine)
during a time that varies depending on the output image spacing set by the
GUI.
    - If I wait until my process stops using CPU time (up to 15 seconds
after the abort), I can re-execute myFunction() without any problem.
    - I've never been able to reproduce the segmentation fault in 1-CPU
mode.

Thanks again for considering this problem.

Didier.

----- Original Message ----- 
From: "Luis Ibanez" <luis.ibanez at kitware.com>
To: "Didier Rajon" <didier at ufl.edu>
Cc: <insight-users at itk.org>
Sent: Saturday, September 11, 2004 7:06 PM
Subject: Re: [Insight-users] Cannot abort properlly multithreaded filters

>
> Hi Didier,
>
> Before continuing on the hunt for a multi-threading issue
> please do the following:
>
> Make sure that after you abort the filter, you call
> ResetPipeline() before attempting to rerun the filter.
>
> It is likely that the segmentation fault is caused by trying
> to execute the pipeline while it is in an invalid state resulting
> from the abort call.
>
> Please let us know what your find.
>
>
>      Thanks
>
>
>        Luis
>
>
>
> --------------------------
> Didier Rajon wrote:
>
> > Hi,
> > I'm having problem trying to abort an itk filter which is multi-threaded
> > (such as itkResampleImageFilter).
> > I'm using itk (v. 1.8), vtk (v.4.2) for the rendering, and Qt (v. 3.3.3)
> > for the user interface on Linux red-hat . In my user interface, I have a
> > dialog window that shows the progress of the filters and allows the user
> > to stop the process by clicking an "abort" button.
> > If I run my program on a single processor machine, everything works
> > fine, I see the progression of the filter on  the progress bar (for this
> > I set an observer on the ProgressEvent), I can abort the filter (By
> > calling the AbortGenerateDataOn() member of the filter), and I can
> > re-execute the filter as I wish.  On the other hand, if I run my program
> > on a 2-processor machine, each time I abort a multi-threaded filter and
> > try to re-execute the filter right after the abort, a "segmentation
> > fault" is produced.
> > I think this has to do with itkProgressReporter. I went to look at the
> > code of itkProgressReporter and it seems to me, that the abort only
> > affects the threadId 0, which means that the second thread (and probably
> > all other threads if I had more than 2 processors) is still running
> > after I abort the filter. If I re-execute the process just after the
> > abort, I get the "segmentation fault". On the other hand, if I wait long
> > enough before I re-execute the filter so that the second thread has time
> > to complete, everything works fine.
> > I also checked the CPU consumption of my system (using the "top"
> > command) and my process is still using CPU time after I abort the
> > filter.  If I re-execute the filter before the CPU time of my process is
> > down to 0, the "segmentation fault" occurs.  If I wait until the CPU
> > time is finally down to 0, then I can re-execute the filter without
problem.
> > Do I need to do something special in order to be able to abort my
> > multithreaded filters, or is this a problem that should be handled by
> > itkProgressReporter?
> >
> > I also noticed that filters that use itkProgressAccumulator (such as
> > itkDiscreteGaussianFilter) are not abortable (what ever the number of
> > processors).  I went to look at the code of itkProgressAccumulator and I
> > found that there is nothing done in this class (nor in
> > itkDiscreteGaussianImageFilter) to propagate the AbortGenerateData flag
> > to the sub-filters of the mini pipe-line.
> > Is this also a problem that I can solve be doing some special things in
> > order to propagate the AbortGenerateData flag, or is this a problem that
> > should be handled by itkProgressAccumulator?
> >
> > Thanks for helping me solving these two problems.
> >
> > Didier.
> >
> >
> >
> > Didier A. Rajon
> > University of Florida
> > Department of Neurological Surgery
> > MBI L2100, PO Box 100265
> > GAINESVILLE, FL, 32610-0265
> > Tel: (352) 294 0144
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users at itk.org
> > http://www.itk.org/mailman/listinfo/insight-users
>
>
>
>
>

_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users