Feature/timespec clocks

[viboes]

Branch to fix the time related issues with non-steady clocks.

Thanks to Austin Beer for his work on PR https://github.com/boostorg/thread/pull/141 and helping me to test this branch.

[austin-beer]

Well, the problem is that we don't know if the user predicate has changed or not, and the time has not been elapsed or reached, and IMO we can not return from the wait_until/wait_for function as we don't know if the signal was lost or not.

Yes, that is the problem.

IIRC, we have added the polling to ensure to be as close to the timeout. Maybe this was an error, and we should prioritize to don't loss notifications :(

Yes, that's why we added the polling. I think we need to prioritize not losing notifications over being close to the timeout. The former is a contract issue. The latter is a QOI issue.

However, we only need to do this for situations where both of the following are true:

1. we don't have access to the predicate
2. the user-provided time is different from the internal clock

For all other situations we either don't need to poll or we can continue polling like we are now. So this issue only affects a subset of our test cases. But for those test cases that are affected, I don't see any solution. The best we can do is make sure that our return value is no_timeout when we don't wait long enough.

Can you think of any better solution?

[viboes]

threadapi=pthread on the command line fixes the issue for me. Thank you.

Glad to hear that. However I have introduced a regression :(

[viboes]

Ok. Granted we shouldn't loss notifications.

Wondering if you have time to add tests that check that we don't loss signal. This will almost duplicate all the current tests.

Hrr, as the loss is accidental, there will be no too much chances to catch the errors :(

[austin-beer]

When does this need to be merged by in order to make it into 1.66?

[viboes]

We have yet 3 weeks. See the release planning http://www.boost.org/development/index.html.

While I would like to deliver it for boost-1.66, I prefer to deliver something that works correctly than delivering something that works most of the times or sometimes as it is now.

Nevertheless I'm confident that this branch has a better quality than the develop branch, so there is always the temptation to deliver.

[austin-beer]

I wholeheartedly agree. I want to be very, very sure that we're not introducing any regressions and that everything works correctly before we release it. If that takes longer than three weeks, then I think that's fine.

Here are the latest results. A lot of the Windows tests are failing again because I commented out some of the Windows changes in the last PR in order to avoid the lost notifications bug, which was causing the test_condition.cpp test to fail (which is how I discovered the issue in the first place).

https://github.com/austin-beer/test-time-jumps

All of the sleep(), try_join(), and try_lock() functions, as well as the functions in future.hpp, should still be fixable because we have access to the predicate in those situations. It's only the non-predicate conditionvariable::wait*() functions that we can't fix.

[austin-beer]

Just FYI, I've started working on a PR to address the lost notifications issue. I should have it ready in a few days.

[viboes]

Perfet

[austin-beer]

A project for my day job is due at the end of this week and so that's been taking up all of my time recently. However, I'm hoping to be able to carve out some time this week to finish this PR. Here are the files that still need work.

win32/basic_timed_mutex.hpp
win32/basic_recursive_mutex.hpp
win32/shared_mutex.hpp
v2/shared_mutex.hpp
concurrent_queues/sync_timed_queue.hpp
concurrent_queues/detail/sync_queue_base.hpp
concurrent_queues/detail/sync_deque_base.hpp

One other issue is that mono_platform_clock::now() isn't yet implemented on Mac OS. Is that something you would have time to work on? I don't have access to a Mac OS platform to test on.

[viboes]

Hi Austin, glad to hear you again.

Yes, I'd have some time this week and then I 'll be on vacations for a week :)

[viboes]

I've implemented mono_platform_clock and mono_platform_timepoint fro MacOs.

https://github.com/boostorg/thread/commit/6d7bc558d0850964c448082bf2b5bec61a0870ae

[austin-beer]

Hi Vicente,

I just wanted to let you know that I haven't forgotten about this PR. I still plan to finish it up when I get the chance. Since we missed the 1.66 deadline, I feel like we have extra time now. And my day job has been keeping me busy. I just need one good day and I should be able to finish updating the remaining files. I hope to be able to make time for that before the end of the year. Here's my list of tasks that still need to be completed.

• Update v2/shared_mutex.hpp (if this implementation is still needed)
• Update win32/basic_timed_mutex.hpp
• Update win32/basic_recursive_mutex.hpp
• Update win32/shared_mutex.hpp
• Make 100 millisecond interval configurable

[viboes]

Hi Austin. I understand. You did already a really good work.

I have had also other things to do on my side and I have not addressed anything since a long time.

Hopping I will had as you say, one day before the end of the year to rework on this PR.

[austin-beer]

Hi Vicente,

I just wanted to see if you're still waiting on anything from me before merging this PR back to develop? I believe I've finished all of the tasks that I needed to do, but if there's anything further you need from me please let me know!

Austin

[viboes]

Really sorry for the delay. I did it just now.

[austin-beer]

Great, thanks!