While I was trying to build the current (1.8.14) library with the mingw compiler I discovered that the library
a) cannot be built as a static library
b) built with C++ interfaces
if I need the lib in multithread safe variant.
While I understand that a) currently is a problem until a mechanism to release thread local storage on thread exit is implemented, I do not understand the restriction on b). Can anyone please explain why the C++ interfaces cannot be built thread safe, as it was possible with 1.8.10?
Thank you very much,
Roland
BTW.: This restrictions are not mingw specific, msvc is the same.
The reason we don't support the higher-level "wrapper" libraries like C++, Fortran, and the high-level (HL) library is that the global lock is at the C API call level, not the wrapper level. Some of these wrapper API calls make multiple C API calls and a context switch during the wrapper call could cause problems.
I say "could" because we have not performed a careful analysis of the issue; we only know that it's a possibility. Hence the labeling of the "wrapper + thread-safe" as "unsupported". The combination can be enabled by turning on unsupported features at configure time, but I would not advise this for important/production software due to the obvious risk of run-time issues. Analyzing and addressing this is on our to-do list, but it hasn't yet moved to the head of the queue.
As for changes between 1.8.10 and 1.8.14, that was probably a result of us bringing CMake up to speed with what the POSIX autotools allow. CMake support was only added (relatively) recently, so we're still working at making it and the autotools behave identically. The autotools have required "unsupported combination" support for thread-safety + C++/Fortran for a long time. The high-level library has not been prohibited under thread-safety, but that was an oversight that will probably be corrected in 1.8.15 in both CMake and the autotools.
Cheers,
Dana
···
-----Original Message-----
From: Hdf-forum [mailto:hdf-forum-bounces@lists.hdfgroup.org] On Behalf Of
Roland Schwarz
Sent: Tuesday, February 03, 2015 3:18 AM
To: HDF Users Discussion List
Subject: [Hdf-forum] Multithreading and CPP
Dear HDF community!
While I was trying to build the current (1.8.14) library with the mingw
compiler I discovered that the library
a) cannot be built as a static library
b) built with C++ interfaces
if I need the lib in multithread safe variant.
While I understand that a) currently is a problem until a mechanism to
release thread local storage on thread exit is implemented, I do not
understand the restriction on b). Can anyone please explain why the C++
interfaces cannot be built thread safe, as it was possible with 1.8.10?
Thank you very much,
Roland
BTW.: This restrictions are not mingw specific, msvc is the same.
The reason we don't support the higher-level "wrapper" libraries like C++, Fortran, and the high-level (HL) library is that the global lock is at the C API call level, not the wrapper level. Some of these wrapper API calls make multiple C API calls and a context switch during the wrapper call could cause problems.
I respect your answer, but I do not try to pretend that I am understanding it. However what puzzles me about the answer is this: Will I suffer from the same issues when I use C++ to call into the hdf5 C-library?
I.e. I write my own C++ classes to use hdf5 at the C level. If C++ in general could not be used with hdf5, that would really be a show stopper!
What should I specifically need to look out for, i.e. what is special about the hdf library that is not present in other c-libraries making it problematic for multithreading?
multithreading, hdf5 and C++ is no problem. It's just the HDF5 C++ library does its own reference-counting in addition to the HDF5-internal reference counting, it's more than a simple API wrapper. The same seems to be the case with the HDF5 HL library.
I'm using HDF5 in a multithreading C++ context myself without issues, but I don't use HDF5 C++ or the HL library.
Cheers,
Werner
···
On 10.02.2015 12:51, Roland Schwarz wrote:
Hi Dana,
thank you for coming back.
On 04.02.2015 at 20:30 wrote Dana Robinson:
The reason we don't support the higher-level "wrapper" libraries like C++, Fortran, and the high-level (HL) library is that the global lock is at the C API call level, not the wrapper level. Some of these wrapper API calls make multiple C API calls and a context switch during the wrapper call could cause problems.
I respect your answer, but I do not try to pretend that I am understanding it. However what puzzles me about the answer is this: Will I suffer from the same issues when I use C++ to call into the hdf5 C-library?
I.e. I write my own C++ classes to use hdf5 at the C level. If C++ in general could not be used with hdf5, that would really be a show stopper!
What should I specifically need to look out for, i.e. what is special about the hdf library that is not present in other c-libraries making it problematic for multithreading?
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Center for Computation & Technology at Louisiana State University (CCT/LSU)
2019 Digital Media Center, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
Ah, I see. The C++ "wrapper code" is not MT safe, while the C API is. So if my C++ code is MT safe everything is fine.
Thank you for the clarification.
Roland
···
On 10.02.2015, 14:23 Werner Benger wrote:
Hi Roland,
multithreading, hdf5 and C++ is no problem. It's just the HDF5 C++ library does its own reference-counting in addition to the HDF5-internal reference counting, it's more than a simple API wrapper. The same seems to be the case with the HDF5 HL library.
On 10.02.2015, 14:23 Werner Benger wrote:
> Hi Roland,
>
> multithreading, hdf5 and C++ is no problem. It's just the HDF5 C++
> library does its own reference-counting in addition to the
> HDF5-internal reference counting, it's more than a simple API wrapper.
> The same seems to be the case with the HDF5 HL library.
>
Ah, I see. The C++ "wrapper code" is not MT safe, while the C API is. So
if my C++ code is MT safe everything is fine.
Thank you for the clarification.
