[Insight-users] Cannot abort properlly multithreaded filters
Didier Rajon
didier at ufl.edu
Mon Sep 13 15:44:59 EDT 2004
Thanks Jim,
I'll check on the bug tracker how this problem evolves.
Let me know if you need more info on how to produce the seg. fault.
Didier.
----- Original Message -----
From: "Miller, James V (Research)" <millerjv at crd.ge.com>
To: "'Didier Rajon'" <didier at ufl.edu>; "Luis Ibanez"
<luis.ibanez at kitware.com>
Cc: <insight-users at itk.org>
Sent: Monday, September 13, 2004 7:47 AM
Subject: RE: [Insight-users] Cannot abort properlly multithreaded filters
> 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
>
More information about the Insight-users
mailing list