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
> >
>
>
>
>
>