Re: [Openexr-devel] OpenEXR thread safety

[Florian Kainz]

Aristarkh A Zagorodnikov wrote:
>                 Hello!
>
>         Recently, while using the OpenEXR-1.2.1 I stumbled upon static
> initialization (staticInitialize() in IlmImf/ImfHeader.cpp). While the rest
> of the library looks thread-safe, this particular place not only looks
> suspicious, it leads to random crashes in attribute registrations for header
> attributes. 
>
>         For now, I "fixed" the problem by placing a "critical section"
> around code which uses IlmImf, but would like to note that fixing this
> problem will surely save users of library from some unexpected errors. Of
> course, I see that adding dependencies on something very platform-dependent
> like thread synchronization library (e.g. WinAPI, pthreads, etc.) is no
> good, yet I believe that it's not the only possible solution. I propose
> addition of some sort of _optional_ initialization function, which _must_ be
> called in a synchronized way. If you do not call the function - you get the
> old behavior with it's problems, but your code is not broken. On the other
> hand if you do - you have all the benefits of thread-safe library without
> any explicit locking.
>
> Aristarkh A Zagorodnikov
> X-Infinity Software



I like your suggestion.  Making some version of staticInitialize()
public is easy enough, and it does not introduce dependencies on an
OS-specific multithreading API.

By the way, Attribute::registerAttributeType() is another function
that is not thread-safe.  If multiple threads call this function
without synchronization, your program will probably crash.
As far as I know, this function is rarely called directly by
application code, but thread-safety issues should probably be
documented somewhere.

Florian