From the HDF5 mailing list:
A little announcement, like I think potentially people in the HDF5 community could be interested in that.
We developed at Blue Brain Project / Human Brain Project a simple, modern, header-only C++ interface to the libhdf5. Mainly to overcome the current limitations of the actual HDF5 C++ interface ( no parallel HDF5, no thread safety, not modern C++ friendly )
It is Open Source and here is a non-explicit list of features :
- It supports both serial and parallel HDF5 with C++ ( contrary to the official bindings that disable c++ bindings when compiled with parallel mode )
- It does not require any compilation, and is embeddable in any project ( Boost Software License ).
- It supports automatic type mapping with C++ types and STL containers : std::vector, std::string, std::array, etc...
- It supports Boost MultiArray and Boost UBLAS for Multi-dimentional dataset and Matrix load/save to/from HDF5 datasets.
- It is design to be modern C++11 / C++14 friendly
- It aims to be minimalsit and does not have any other dependencies than libhdf5 itself
- It does not support the integrality of the libhdf5 API for now, but If you have any interest or comment about it, let us know.
Adrien Devresse - Blue Brain Project / Human Brain Project
A question on the mailing list:
I'm interested in how you handle thread safety. I've only had a quick look, but looking at e.g. SliceTraits
::read, I can't see any lock being taken before the call to H5Dread (nor around the surrounding C++ code). Do you assume the HDF5 library is compiled in thread safe mode? And is are the wrappers themselves thread safe? -- Elvis Stansvik
An answer to the question:
For now, you get the thread safety provided by the HDF5 library yes. If libhdf5 has been compiled with thread safety, then HighFive is thread safe. If not, you need to do the locking yourself unfortunately. All the wrappers around libhdf5 provided by HighFive are thread-safe.