[Insight-developers] Thread safety concerns with IO Factory registration

[Bradley Lowekamp]

Hello,

I believe there are potential threading issues related to the current mechanism of registering ImageIOs.

Currently, there are no locks in the itkObjectFactory, which contains essentially the global list of Factories in the m_RegisteredFactories variable. With this model it is clearly bad to have concurrent threads trying to register new factories at the same time. And by bad I mean undefined behavior [1].

Prior to the refactoring, registration of all the "ITK_AUTOLOAD_PATH" factories and ImageIOs factories were done at the first New. This essentially means that the first itk New was a critical section where the onerous was on the user to ensure safety. This was not to hard, and usually just happened.

After the refactoring, it is my understanding that the the ImageIO Factories are registered by static initialization in each translation unit which includes tikImageFileReader.h. As usually C++  does not specify the thread safety of static initialization. So my assumption is that the compilers don't automatically add it. So here is the problem I see, it appears to be unsafe to have multiple threads enter certain translation units at the same time. This will be an insidious bug to track down, and not something which can be ensured by users of ITK.

The New for all most all itkObjects goes through the itkObjectFactory to see if there is a registered overload. This means that adding locks to many parts of the ObjectFactory will be entirely too costly. 


Now, this is all theory and I have not actually run into this problem. So, I am going to write a test and try to launch 100 threads into 100 translation unit as see what happens.

Additionally, it's not clear to me how the factories don't get registered multiple times.

[1] http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Thanks,
Brad

========================================================
Bradley Lowekamp  
Medical Science and Computing for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120412/86547cfe/attachment.htm>