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

[Bradley Lowekamp]

Hello,

As you said on windows this a problem, because these ImageIO libraries are still static in a shared build. So there may be multiple of the HasBeenRegistered for each dll. While for some application it's easy to control where the registration occurs for larger its much more complex.

Perhaps specifically consider SimpleITK build with ITK with both shared libraries. In SimpleITK only the registration occurs just in the IO sub-library. However, if the applications wants to use both ITK and SimpleITK, its very likely that the registration will happen again. If I understand what in means to link the static libraries to a dll, this may reck havoc on third party libraries singleton-type data as there may be multiple versions in each dll.

Slicer is one example of the above situation with ITK and SimpleITK. Additionally, it has extensions where a single file gets compiled into both a dynamic library and an executable. The current define ITK_NO_IO_FACTORY_REGISTER_MANAGER before "using ITK", does not provide the needed flexibility for such situations.

Does it sound easier to address these issues for each application or could the ImageIO be made shared on windows?

The reason I am thinking about this issue so much is the quarter million of valgrind errors I got from mixing static ITK libraries with shared simpleITK libraries[1] mostly appear related to HDF5 and GDCM static initialization and destruction. And have been pondering what this means for Windows libraries.

http://open.cdash.org/viewDynamicAnalysisFile.php?id=2736128

Brad

On Apr 12, 2012, at 1:51 PM, Brad King wrote:

> On Thu, Apr 12, 2012 at 1:23 PM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> static bool MetaImageIOFactoryHasBeenRegistered;
>> 
>> I don't under stand how MetaImageIOFactoryHasBeenRegistered gets initialized
>> before usage. And then is the static initialization fiasco [1] an issue?
> 
> When the type of a global is a plain-old-data (POD) type the compiler
> default-initializes it to zero (false for bool).  We purposely take
> advantage of default initialization because the code that
> modifies/tests the variable may be invoked during static initalization
> of *another* translation unit.  If we had an explicit initializer then
> it would overwrite whatever work had been done so far (from other
> translation units) when the translation unit defining the global is
> explicitly initialized.
> 
> This approach is the same as some vendors' standard libraries use to
> initialize singletons like "cout" and "cerr" AFAIK.
> 
> -Brad K

========================================================
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/20120413/769c785f/attachment.htm>