Fwd: RE: [Insight-users] Thread safety of itkMultiThreader
Hannu Helminen
Hannu.Helminen.0001@dosetek.varian.com
Thu, 03 Oct 2002 13:34:16 +0300
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.