Migrating from Boost.Thread to std

[SergioRAgostinho]

I'm just opening this one to mention I'm working on it. I've incorporated the corresponding commit from #2382 and I'm building up on it.

Migration list:

• boost::thread - Transition from boost::thread to std::thread. #3060
• boost::condition_variable
• locks & mutexes
• Remove search from Boost.Thread component in CMakeLists.txt

[SergioRAgostinho]

The current status:

I've migrated common and io, but there's still a number of targets in tools, apps and tests to go.

The current policy, ignoring the obvious ones, has roughly been:

• boost::this_thread::sleep -> std::this_thread::sleep_for
• boost::mutex::scoped_lock -> std::unique_lock<std::mutex>.

I'm currently dealing with an issue with boost::shared_lock which was used in outofcore_base.h. Shared locks are only available in the standard from 2017 onwards. Basically, converting it to a unique_lock will kill performance a little, since the shared_lock seems to be designed with the multiple reader single writer case in mind, where in the unique_lock everything is exclusive.

[taketwo]

Can we just keep boost::shared_lock in that module? We are not going to drop Boost dependency anyway. Thus I don't see why we need to sacrifice performance and (potentially) introduced hard-to-catch bugs just to get rid of some Boost class?

[SunBlack]

Shared locks are only available in the standard from 2017 onwards.

Sure? std::shared_lock is labeled as C++14 here.

[SergioRAgostinho]

Shared locks are only available in the standard from 2017 onwards.

Sure? std::shared_lock is labeled as C++14 here.

Very very late answer. The issue comes from this line in that same page

Mutex - the type of the shared mutex to lock. The type must meet the SharedMutex requirements

However shared mutexes were only introduced in C++17. However, it appears shared timed mutexes were created for C++14 and appear to provide a superset of the functionality of the shared mutex. The shared mutex might have appeared later to reduce unwanted functionality.