[Feature Request] missing basic H5F_[un]lock(file_id)

[chacha21]

HDF 1.12

In the context of a single HDF5 file (with a single file_id) containing multiple datasets, I encounter crashes when multiple threads perform reading operations (involving hyperslabs) in the different datasets, even if HDF5 was compiled with thread safety.

I understand that basic thread safety currently relies on a giant lock for each and every API call, but does not protect a sequence of operation (H5F_getspace(), H5S_selectHyperslab, H5D_read...) : that should explain the bug.

Since I work with a single file_id, I cannot expect the SWMR scheme of H5F_open() flags to help.
In my context, it is really not possible to open the file multiple times (because of #1978)

As a workaround, I successfully used a OS-provided mutex associated to the the file_id value, and enclosed my threaded sequences of operations in mutex-protected sections. But it is a pity to rely on an external locking scheme.

After thinking about it, I think that what I need is a very basic H5F_[un]lock(hid_t file_id), or H5F_[un]lock_read(hid_t file_id)/H5F_[un]lock_write(hid_t file_id) if SWMR is possible.

And since it really seems very basic, I wonder why (as of my knowledge), nothing similar is available in the current API.

[jwsblokland]

Hello HDF Group,

If the proposed functions (or something similar) by @chacha21 will be implemented would it be possible to also add function like H5F_is_locked(hid_t file_id) to check if the file is locked or not. In some rare case, I have seen that the HDF5 has been locked and you get all kind of errors once to try to open it again. With this function I can implemented a more graceful error and give a suggestion of how to resolve the problem.

[chacha21]

If the proposed functions (or something similar) by @chacha21 will be implemented would it be possible to also add function like H5F_is_locked(hid_t file_id) to check if the file is locked or not.

This should rather be done through a H5F_trylock(hid_t file_id, int timeout_ms) with a timeout of 0.

[fortnern]

You shouldn't see failures with threadsafe enabled, unless one of the threads is changing assumptions made by the other threads (such as resizing the dataset). Do you have an example program that shows the issue?

Also, I'm not sure what you mean by "sequence of operation". The functions you list don't exist in the repository.

[chacha21]

unless one of the threads is changing assumptions made by the other threads (such as resizing the dataset)

I did not put sample code, but you are pointing exactly at the problem.
I have a file_id containing multiple chunked datasets, that can be resized.
I have worker threads, one thread per dataset, that can write and extend the datasets as needed.
If I don't protect my thread operations within a mutex, I have random crashes inside the HDF5 API itself.

[fortnern]

What errors do you see?

[fortnern]

And are you only extending the datasets or also shrinking them (along any dimension)?

[chacha21]

And are you only extending the datasets or also shrinking them (along any dimension)?

I will post sample code (in a few days, time to make a minimal project)

[chacha21]

What errors do you see?

random crashes

[chacha21]

I have created a minimal project to exhibit the bug... that was finally my fault.
I found an unexpectedly shared mutable variable in my original code that required the lock for proper thread concurrency.
Without such a variable, I do not reproduce the bug I mentioned earlier.

However, my code is not fundamentally incorrect : it just requires proper locking for some custom state.
So the current issue is still valid : instead of creating a lock myself, I would like to be able to rely on a H5F_[un]lock API, whatever the "USE_FILE_LOCKING" compile option.

The "bug" tag is now incorrect, though, only "feature request"

[bls-lehoai]

@chacha21
same problem here.
how to do you "If I don't protect my thread operations within a mutex"?
can u give me an example or a clue? (sorry i am a newbie in C++)

[chacha21]

@chacha21 same problem here. how to do you "If I don't protect my thread operations within a mutex"? can u give me an example or a clue? (sorry i am a newbie in C++)

There is no generic answer. It means that you are using your own mutexes to protect some parts of your code that could be executed in parallel by multiple threads.
You can use mutexes from C++11 (std::mutex...), OS-provided (CreateMutex() under windows...), or from a third-party API that you are using.
If you are not familiar with the subject, you have to learn about locking, resource protection, mutex, semaphore...

[qkoziol]

I'm not certain what you are asking for here - if the HDF5 library is configured & built w/threadsafety, it is not possible to have concurrent operations working within the library, so it's impossible to have crashes from this. The library implements the mutex to guard against these problems, so there's no user code necessary - just call the (built with threadsafety enabled) library routines you want.

[chacha21]

I changed my mind about my request after sorting out that the sync bug was on my side.
It became a feature request, not a bug report.

My request is to let HDF5 provide a global file-lock interface as a handy feature to the user of the API, so that he won't have to implement the lock himself.

• no need for the API user to clutter his code with another mutex API, he can rely on the one HDF5 is already using
• a giant file-lock scheme might be desirable if the API user is not responsible for the fact that HDF is built w or w/o thread safety, and that he still wants to be sure about the mutual exclusion of some concurrent API calls.

[qkoziol]

You are still mixing the idea of thread safety for API calls (which involve mutexes, etc. and is already implemented) and locking a file (which will not prevent concurrent access from threads in the same process).

[qkoziol]

Adding file lock / unlock APIs may still be a good idea, but it won't solve the problem that you are describing.