diff options
author | Dana Robinson <43805+derobins@users.noreply.github.com> | 2021-05-14 13:00:05 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-05-14 13:00:05 (GMT) |
commit | 8977e43b7766f4f817fa067b2d22e84b775bf5a2 (patch) | |
tree | ff2414b18c330b612c202fc2338ee915d31e11d8 /release_docs | |
parent | 53cfafff061071dca0d74617629c66350f66d6cc (diff) | |
download | hdf5-8977e43b7766f4f817fa067b2d22e84b775bf5a2.zip hdf5-8977e43b7766f4f817fa067b2d22e84b775bf5a2.tar.gz hdf5-8977e43b7766f4f817fa067b2d22e84b775bf5a2.tar.bz2 |
Brings the thread-safety recursive writer locks to 1.12 (#466)
* First cut at replaceing the existing mutex with a recursive R/W lock.
This implementation has the following issues:
1) pthreads implementation only -- we still need a windows version.
2) must investigate thread cancelation issues
3) Error reporting is very poor. I followed the error reporting on
the existing thread safe code, but this should be re-visited and
improved.
Code is currently setup to use the new recursive R/W lock instead of
the global mutex to control entry to the library in threadsafe builds.
To revert to the global mutex, set H5TS__USE_REC_RW_LOCK_FOR_GLOBAL_MUTEX
in H5TSprivate.h to FALSE.
Added a reasonably robust regression test for the reursive R/W lock
in test/ttsafe_rec_rw_lock.c
Note that the change to hl/src/H5LTanalyse.c is an artifact of clang-format.
Tested serial threadsafe debug and production on jelly, and also regular
serial / debug.
On Windows builds, the new recursive R/W lock should not be built and
we should use the existing global mutex -- however this is not tested
at this time.
* Updates CMake to build recursive RW lock test
* Updates to allow building on Windows
* Moves #if statements to better protect non-RW lock code
* Adds configure and CMake options for the recursive RW locks
* Committing clang-format changes
* Updates RELEASE.txt and the build options
* Renames H5TS RW lock things
* Makes struct members platform independent
Also removes _ptr from identifiers
* Partial thread-safety RW locks platform independence
* Committing clang-format changes
* Pthreads side of things is platform-independent now
* Formatted source
* Added Windows equivalents for some Pthreads calls
* Rename H5TS takedown call to destroy
* Reorg of RW lock code
* Committing clang-format changes
* Changes to Pthreads code after development on Visual Studio
* Moves stats macros to static inline functions and tidies memory allocs
* Converts RW lock print stats call to use C99 formatting
* Fixes typos
* Formatted source
* Updates the RELEASE.txt note to indicate no Win32 threads support
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
Diffstat (limited to 'release_docs')
-rw-r--r-- | release_docs/RELEASE.txt | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/release_docs/RELEASE.txt b/release_docs/RELEASE.txt index 807d3ab..66b78ac 100644 --- a/release_docs/RELEASE.txt +++ b/release_docs/RELEASE.txt @@ -47,6 +47,31 @@ New Features Configuration: ------------- + - Added an option to make the global thread-safe lock a recursive R/W lock + + Prior to this release, the HDF5 library supported multi-threaded + applications by placing a recursive global lock on the entire library, + thus allowing only one thread into the library at a time. + + While this is still the default, the library can now be built with the + recursive global lock replaced with a recursive read / write (R/W) lock + that allows recursive writer locks. + + Currently, this change results in no functional change in the HDF5 + library, as all threads will have to acquire a write lock on entry, and + thus obtain exclusive access to the HDF5 library as before. However, the + addition of the recursive R/W lock is a prerequisite for further work + directed at allowing some subset of the HDF5 API calls to enter the + library with read locks. + + CMake: HDF5_USE_RECURSIVE_RW_LOCKS (default: OFF, advanced) + + Autotools: --enable-recursive-rw-locks [default=no] + + This feature only works with Pthreads. Win32 threads are not supported. + + (DER - 2021/05/10) + - CMake no longer builds the C++ library by default HDF5_BUILD_CPP_LIB now defaults to OFF, which is in line with the |