Fwd: RE: [Insight-users] Thread safety of itkMultiThreader : Aborting filter execution

Miller, James V (Research) millerjv@crd.ge.com
Thu, 3 Oct 2002 12:56:35 -0400


Luis,

Could this check be put into the progress reporter?

The progress reporter would return the value of m_AbortGenerateData.



> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> Sent: Thursday, October 03, 2002 10:30 AM
> To: Hannu Helminen
> Cc: insight-users@public.kitware.com; Miller, James V (Research)
> Subject: Re: Fwd: RE: [Insight-users] Thread safety of 
> itkMultiThreader
> : Aborting filter execution
> 
> 
> Hi Hannu,
> 
> About the mechanism for stopping filters during execution:
> 
> The itkProcessObject has a boolean member variable:
> 
>           m_AbortGenerateData
> 
> That can be Set/Get with
> 
>          SetAbortGeneratData( );
>          GetAbortGeneratData( );
> 
> Since all ITK filters derive from the ProcessObject, users can
> stop filter from a GUI by invoking
> 
>         myFilter->SetAbortGenerateData( true );
> 
> or
>        
>         myFilter->AbortGenerateDataOn();
> 
> 
> The problem is that filters are not checking for this condition
> in their inner loops.....
> 
> Right now, this condition is only tested in the 
> itkStreamingImageFilter.
> 
> So, it seems that we will have to visit all the filters and add this
> checking in order to allow users to abort a process....
> 
> Once the filters are aborted they will send an StopEvent() that
> a GUI can use to keep the user informed.
> 
> In this way you can exit a filter nicely... without throwing 
> exceptions.
> 
> Thanks for pointing this out
> 
> 
>     Luis
> 
> ===================================
> 
> Hannu Helminen wrote:
> 
> > In my suggested patch, I only store an exception flag in the worker 
> > thread to ThreadInfoStruct, which is then read by the main thread.
> >
> > Better option would be to store the actual exception 
> object. But there 
> > are some difficulties in this approach:
> >
> > 1) It is not possible to determine which exception occurred in run 
> > time. Even though ITK only throws itk::ExceptionObject, 
> user code or 
> > the operating system can throw std::exception or even 
> something else. 
> > Catching these objects by correct type and then re-throwing 
> them will 
> > be quite tedious.
> >
> > 2) Copying the exception object usually requires allocating 
> new memory 
> > from the heap. If the original exception was caused by a low memory 
> > condition, this may cause another exception, which will not 
> be handled.
> >
> > If the intent is to propagate the reason of the exception 
> up, probably 
> > best option would be to catch for both std::exception 
> (which is also a 
> > superclass of itk::ExceptionObject) and the ellipsis construct 
> > "catch(...)". The reason code from std::exception::what() 
> function is 
> > then stored to a (perhaps pre-allocated) buffer, which is then 
> > re-thrown in the main thread as an itk::ExceptionObject.
> >
> >
> > There should be no need to modify the ThreadedGenerateData() 
> > functions, since the exception handling is in a separate function 
> > within the itk::MultiThreader.
> >
> > However, as a consequence of this change, it *could* be possible to 
> > clean up the interface of the multitheader callback function. 
> > Currently it is
> >
> > ITK_THREAD_RETURN_TYPE CallbackFunction(void *argument)
> >
> > where the return type depends on the threading model used, and the 
> > argument has to be cast with reinterpret_cast. In interest of code 
> > clarity, both the cast and the return value could be moved 
> to inside 
> > itk::MultiTheader, and the signature could be e.g.
> >
> > void CallbackFunction(MultiThreader::ThreadInfoStruct *argument)
> >
> > This would also allow for the possibility of compiling in 
> support for 
> > two or more threading models simultaneously. Currently this is not 
> > possible, since the choice of ITK_THREAD_RETURN_TYPE is made at 
> > compile time.
> >
> >
> > I am not familiar enough with the ITK's event model to know 
> how to use 
> > it to interrupt a lengthy calculation. In general the problem with 
> > such voluntary methods of aborting an algorithm is that 
> abortion has 
> > to be anticipated in each algorithm separately. Taking a concrete 
> > example, how should I interrupt the code in 
> > itkStatisticsImageFilter::ThreadedGenerateData()? As far as 
> I can see, 
> > the only way to interrupt this code before iteration is 
> complete is to 
> > throw an exception from within the progress reporter.
> >
> > Hannu
> >
> >
> > PS. The subject line should of course read "exception safety", not 
> > "thread safety" ;-) But that was probably obvious.
> >
> >
> >
> >> From: "Miller, James V (Research)" <millerjv@crd.ge.com>
> >> To: "'Hannu Helminen'" <Hannu.Helminen.0001@dosetek.varian.com>,
> >>         insight-users@public.kitware.com
> >> Subject: RE: [Insight-users] Thread safety of itkMultiThreader
> >> Date: Wed, 2 Oct 2002 12:48:26 -0400
> >> X-Mailer: Internet Mail Service (5.5.2653.19)
> >>
> >> I think your model of the "correct behavior" sounds good.
> >> I haven't looked though your changes enough to determine how the
> >> worker threads communicate the exception to the main thread. Is
> >> it merely the return status indicating an exception occurred or
> >> is the actual exception object passed to the main thread?
> >>
> >> Would we need to change the ThreadedGenerateData() methods
> >> in each filter to catch the exceptions or is that catch
> >> encapsulated in the Multithreader code?
> >>
> >> A note on your use of exceptions.  We decided internally to
> >> restrict our use of exceptions to events that were truely
> >> exceptional (ran out of memory, disk error, etc.) and to use
> >> Observers/Events to capture operations like a user aborting
> >> a filter. Would ITK's events have worked for you here?
> >
> >
> > Hannu Helminen
> > Varian Medical Systems Finland Oy
> > This is a temporary mail account that may get deleted after 
> spambots 
> > harvest the email address.
> >
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users@public.kitware.com
> > http://public.kitware.com/mailman/listinfo/insight-users
> >
> 
> 
> 
> 
>