boost::this_thread::sleep_for is allowed to sleep longer than the
requested sleep time. This seems to happen especially on virtualized
systems, such as CircleCI.
* Fixed try_unlock_shared_and_lock_until/for() and
try_unlock_shared_and_lock_upgrade_until/for() so that they wait on the
correct condition variable for the associated predicate.
* Fixed try_unlock_shared_and_lock_until/for() and
try_unlock_upgrade_and_lock_until/for() so that they take the
write_entered_ flag before waiting for all shared readers to unlock. This
prevents new readers from taking a shared lock or new writers from taking
the exclusive lock while these functions are waiting to take the
exclusive lock.
* Changed notify_all() calls to occur while the mutex is being held to be
consistent with the notify_one() calls and the existing
pthread/shared_mutex.hpp implementation.
* Added BOOST_THREAD_PROVIDES_SHARED_MUTEX_UPWARDS_CONVERSIONS ifdefs.
* Added BOOST_ASSERT() statements to verify correct usage and operation.
* Fixed an incorrect test case that the BOOST_ASSERT() statements
uncovered.
* Added comments to explain certain design decisions.
- Fixed build failures on Windows. The timespec struct is not supported by older versions of Visual Studio. I changed the internal representation inside of the *_timespec_timepoint classes to a boost::intmax_t representing the number of nanoseconds since the epoch.
- Fixed some functions that wouldn't execute at all if they were provided a negative time duration or an absolute time that was in the past. From what I understand, they should instead execute once and then return immediately.
- Moved pthread/timespec.hpp to detail/timespec.hpp.
- Deleted detail/internal_clock.hpp and moved the seven relevant lines into detail/timespec.hpp. This keeps all of the internal clock declarations in one place.
- Renamed thread_detail::internal_clock_t to detail::internal_chrono_clock to be consistent with and yet clearly differentiated from detail::internal_timespec_clock.
- Removed "using namespace chrono" to eliminate ambiguious namespace resolution when referencing detail::internal_chrono_clock.
- Re-enabled a few tests on Windows that had previously been disabled. I want to see whether or not they still need to be disabled.