This is an archive of the discontinued LLVM Phabricator instance.

libc++ tests: wait_until.pass test sporadically fails (bug 21998)
ClosedPublic

Authored by iid_iunknown on Dec 21 2014, 8:23 AM.

Details

Summary

Hello Howard,

While running the libc++ tests on our ARM boards, we encounter sporadic failures of the two tests:
test/std/thread/futures/futures.shared_future/wait_until.pass.cpp
test/std/thread/futures/futures.unique_future/wait_until.pass.cpp

The worker thread might not finish yet when the main thread checks its result.
I filed the bug 21998 for this case: http://llvm.org/bugs/show_bug.cgi?id=21998

Would you be able to review this please?
Thank you.
Oleg

Diff Detail

Event Timeline

iid_iunknown retitled this revision from to libc++ tests: wait_until.pass test sporadically fails (bug 21998).
iid_iunknown updated this object.
iid_iunknown edited the test plan for this revision. (Show Details)
iid_iunknown added a reviewer: howard.hinnant.
iid_iunknown set the repository for this revision to rL LLVM.
iid_iunknown added a subscriber: Unknown Object (MLST).
EricWF added a subscriber: EricWF.

Adding the appropriate reviewers and putting in my two cents.

test/std/thread/futures/futures.shared_future/wait_until.pass.cpp
86–88

While this patch may fix the race condition that you and others have seen I think it introduces the possibility that the test could hang.

Isn't in possible (although very unlikely) that func1 will execute lines 48-53 and set thread_state = Exiting before we enter line 88?
It seems we depend on std::this_thread::sleep_for(ms(500)) to prevent this from happening. Please let me know if I am mistaken.

With our change the race condition now takes 500ms as opposed to 100ms (as mentioned in PR21998). If we are going to depend on the call to std::this_thread::sleep_for at all then why not depend on it entirely and increase the amount of time we sleep for? At least that way we prevent these tests from becoming dependent on std::mutex, std::unique_lock and std::condition_variable.

I'm also a little uncomfortable using explicit locking when testing <future>. My concern is that it might hide race conditions that would otherwise be detectable from sporadic test failures or instrumentation like thread sanitizer. However this concern could be entirely unfounded.

iid_iunknown removed rL LLVM as the repository for this revision.

Patch updated taking into account the review remarks.

iid_iunknown set the repository for this revision to rL LLVM.Dec 23 2014, 7:15 AM
jroelofs accepted this revision.Jan 12 2015, 8:40 AM
jroelofs edited edge metadata.

I'd add some asserts in the main thread to call out what the worker thread state is supposed to be in a few places (to improve readability). Other than that, LGTM.

This revision is now accepted and ready to land.Jan 12 2015, 8:40 AM
EricWF accepted this revision.Jan 30 2015, 8:34 PM
EricWF edited edge metadata.

LGTM after the inline comment in answered. Do you need somebody to commit this for you?

test/std/thread/futures/futures.shared_future/wait_until.pass.cpp
31

Why use a relaxed and not strict memory ordering? If we use strict ordering (the default) then we can just use the assignment operators to write to thread_state and we can remove this function.

EricWF closed this revision.Feb 10 2015, 5:27 PM