Within the shared state methods do not unlock the lock guards manually. This
could cause a race condition where the shared state is destroyed before the
method is complete.
llvm-svn: 239577
The test class 'G' reads and writes to the same static variables in its
constructor, destructor and call operator. When threads are
constructed using `std::thread t((G()))` there is a race condition between the
destruction of the temporary and the execution of `G::operator()()`.
The fix is to simply create the input before creating the thread.
llvm-svn: 233946
Summary:
The summary of the bug, provided by Stephan T. Lavavej:
In shared_timed_mutex::try_lock_until() (line 195 in 3.6.0), you need to deliver a notification. The scenario is:
* There are N threads holding the shared lock.
* One thread calls try_lock_until() to attempt to acquire the exclusive lock. It sets the "I want to write" bool/bit, then waits for the N readers to drain away.
* K more threads attempt to acquire the shared lock, but they notice that someone said "I want to write", so they block on a condition_variable.
* At least one of the N readers is stubborn and doesn't release the shared lock.
* The wannabe-writer times out, gives up, and unsets the "I want to write" bool/bit.
At this point, a notification (it needs to be notify_all) must be delivered to the condition_variable that the K wannabe-readers are waiting on. Otherwise, they can block forever without waking up.
Reviewers: mclow.lists, jyasskin
Reviewed By: jyasskin
Subscribers: jyasskin, cfe-commits
Differential Revision: http://reviews.llvm.org/D8796
llvm-svn: 233944
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
Reviewers: howard.hinnant, mclow.lists, danalbert, jroelofs, EricWF
Reviewed By: jroelofs, EricWF
Subscribers: EricWF, mclow.lists, aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D6750
llvm-svn: 228783
Eric Fiselier