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

[Hannu Helminen]

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.