You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After some long time, I was updating boost from 1.58 to the latest version.
And after resolving some minor issues due to updating, everything worked fine on my windows machine and all tests of my application passed. Unfortunately, when using linux (RHEL 7), there was always some strange behavior with threads and mutexes.
I created some minimal example to investigate the issues and I have the same application that runs 3 seconds on windows and returns properly but runs for hours on my linux system and never finishes.
It seems that linux now prefers boost::shared_lock<boost::shared_mutex> over boost::unique_lock<boost::shared_mutex>. As long as there are shared locks that own the mutex, no unqiue lock will get the mutex. While new shared locks still get the mutex. windows still prefers boost::unique_lock<boost::shared_mutex>
Here is the application - sorry for all the additional defines - I also wanted to test it with stl which had the same behavior.
Runtime on windows 10, msvc: 3s
Runtime on RHEL 8.4 boost 1.66: 12s (still ok)
Ubuntu WSL boost 1.71 with g++ or clang (same behavior), : stopped watching after > 20 minutes
solved my issue and linux and windows worked in the same way.
I'm just not sure if using BOOST_THREAD_V2_SHARED_MUTEX is a valid and tested solution and if the compile flag will also be available in future boost releases.
The text was updated successfully, but these errors were encountered:
After some long time, I was updating boost from 1.58 to the latest version.
And after resolving some minor issues due to updating, everything worked fine on my windows machine and all tests of my application passed. Unfortunately, when using linux (RHEL 7), there was always some strange behavior with threads and mutexes.
I created some minimal example to investigate the issues and I have the same application that runs 3 seconds on windows and returns properly but runs for hours on my linux system and never finishes.
It seems that linux now prefers
boost::shared_lock<boost::shared_mutex>
overboost::unique_lock<boost::shared_mutex>
. As long as there are shared locks that own the mutex, no unqiue lock will get the mutex. While new shared locks still get the mutex. windows still prefersboost::unique_lock<boost::shared_mutex>
Here is the application - sorry for all the additional defines - I also wanted to test it with stl which had the same behavior.
Runtime on windows 10, msvc: 3s
Runtime on RHEL 8.4 boost 1.66: 12s (still ok)
Ubuntu WSL boost 1.71 with g++ or clang (same behavior), : stopped watching after > 20 minutes
It seems that there was a commit for boost 1.68 that changed the shared mutex preference completely, so that unique locks now run into starvation, as long as shared locks hold a mutex: eef7293#diff-d452c62020a873f8c21ba3df4841794a32183e83e50d52f7e58e7d81da389361
Here is the minimal sample code - make sure you compile with "USE_BOOST":
Using
g++ -g -O2 -DUSE_BOOST -DBOOST_THREAD_V2_SHARED_MUTEX -o boostM stl_vs_boost.cpp -std=c++17 -pthread -lboost_system -lboost_thread -lboost_iostreams -lboost_date_time -lboost_random -lboost_chrono && ./boostM
solved my issue and linux and windows worked in the same way.
I'm just not sure if using BOOST_THREAD_V2_SHARED_MUTEX is a valid and tested solution and if the compile flag will also be available in future boost releases.
The text was updated successfully, but these errors were encountered: