[Insight-users] Thread safety of itkMultiThreader

[Miller, James V (Research)]

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?



> -----Original Message-----
> From: Hannu Helminen [mailto:Hannu.Helminen.0001@dosetek.varian.com]
> Sent: Wednesday, October 02, 2002 3:42 AM
> To: insight-users@public.kitware.com
> Subject: [Insight-users] Thread safety of itkMultiThreader
> 
> 
> 
> Hello all,
> 
> Overall, the exception safety of itk is very good. But one area where 
> exceptions are not gracefully handled is the 
> itkMultiThreader. If any of 
> the worker thread throws, this causes at least in Win32 a 
> program fault, 
> since each thread is expected to catch its own exceptions. 
> And also if the 
> main thread fails, it does not clean up the worker threads 
> correctly, as it 
> should.
> 
> I think that the correct behavior would be for each worker 
> thread to catch 
> all exceptions using the catch(...) construct, and then 
> signal the main 
> thread that a failure has occurred. And if the main thread 
> notices the 
> problem, it first cleans up the other threads and then 
> re-throws an exception.
> 
> I have been bitten by this recently: I have created a 
> progress reporter 
> which also lets the user abort the algorithm, which is 
> implemented with an 
> exception. This seems to work OK otherwise but not from within the 
> multi-threaded algorithms.
> 
> To illustrate my point, I have attached a patch. This change has been 
> compiled and tested only against Win32 and no threading 
> models, because I 
> only have access to those. Nevertheless I attempted to make 
> the code work 
> also in the pthreads and sproc threading models. While I was 
> at it, I also 
> re-structured the code so that the exception handling will 
> only be written 
> once, and all the threading model specific extensions are 
> more grouped 
> together.
> 
> Since the idea is to illustrate a point, only the SingleMethodExecute 
> method was re-touched. But if this patch is accepted, I can 
> create another 
> one which also fixes the MultipleMethodExecute.
> 
> Best regards,
> Hannu Helminen
> Varian Medical Systems Finland Oy
>