[Insight-users] Cannot abort properlly multithreaded filters
Didier Rajon
didier at ufl.edu
Sun Sep 12 21:11:06 EDT 2004
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
>
>
>
>
>
More information about the Insight-users
mailing list