Different boost::shared_mutex behavior on linux & windows
- Dominant language
- C++
- Stars
- 214
- Forks
- 171
- PR merge metrics
- No merged PRs in 30d
Description
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` over `boost::unique_lock`. 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`
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: https://github.com/boostorg/thread/commit/eef72939322916a03f9d797793c755f57aa59f03#diff-d452c62020a873f8c21ba3df4841794a32183e83e50d52f7e58e7d81da389361
Here is the minimal sample code - make sure you compile with "USE_BOOST":
```
// stl_vs_boost.cpp
// g++ -g -O2 -DUSE_BOOST -o boostM stl_vs_boost.cpp -std=c++17 -pthread -lboost_system -lboost_thread -lboost_iostreams -lboost_date_time -lboost_random -lboost_chrono && ./boostM
#include
#include
#include
#include
#include
#include
#ifdef USE_BOOST
#include
#include
#include
typedef boost::thread Thread;
typedef boost::shared_mutex SharedMutex;
typedef boost::unique_lock UniqueLock;
typedef boost::shared_lock SharedLock;
#define MUTEX_STRING "boost"
#else
typedef std::thread Thread;
typedef std::shared_mutex SharedMutex;
typedef std::unique_lock UniqueLock;
typedef std::shared_lock SharedLock;
#define MUTEX_STRING "STL"
#endif
SharedMutex myMutex;
const size_t maxIterations = 20000000;
int sharedLocking() {
for (size_t i = 1; i < maxIterations; ++i) {
SharedLock a(myMutex);
if (i % 200 == 0) {
std::cout << "." << std::flush;
}
std::this_thread::sleep_for(std::chrono::milliseconds(5));
}
std::cout << "Finished local" << std::flush;
return 0;
}
int uniqueLocking() {
std::cout << "_" << std::flush;
UniqueLock a(myMutex);
std::cout << "|" << std::flush;
std::cout << "Unique" << std::endl << std::flush;
std::this_thread::sleep_for(std::chrono::seconds(2));
exit(0);
return 0;
}
int main(int argc, char **argv) {
std::cout << "Using " << MUTEX_STRING << " mutexes" << std::endl;
std::cout << " starting ..." << std::endl;
for (int i = 0; i < 128; ++i) {
std::shared_ptr tmpThread = std::make_shared(&sharedLocking);
tmpThread->detach();
}
std::this_thread::sleep_for(std::chrono::seconds(1));
std::shared_ptr myThread = std::make_shared(&uniqueLocking);
std::shared_ptr myThread2 = std::make_shared(&uniqueLocking);
myThread->join();
return 0;
}
```
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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.