Because <atomic> can now be used in C++03 there is no need for the test_atomic.h header.
This commit removes the header and converts all usages to use <atomic> instead.
llvm-svn: 245468
std::packaged_task requires variadic templates and is #ifdef out in C++03.
This patch silences the tests in C++03. This patch also rewrites the .fail.cpp tests so that they use clang verify.
llvm-svn: 245413
Summary:
This patch attempts to fix the last 3 TSAN failures on the libc++ bot (http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-tsan/builds/143). This patch also adds a `Atomic` test type that can be used where `<atomic>` cannot.
`wait.exception.pass.cpp` and `wait_for.exception.pass.cpp` were failing because the test replaced `std::terminate` with `std::exit`. `std::exit` would asynchronously run the TLS and static destructors and this would cause a race condition. See PR22606 and D8802 for more details.
This is fixed by using `_Exit` to prevent cleanup.
`notify_all_at_thread_exit.pass.cpp` exercises the same race condition but for different reasons. I fixed this test by manually joining the thread before beginning program termination.
Reviewers: EricWF, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11046
llvm-svn: 245389
This patch fixes LWG issue 2422 by removing the DECAY_COPY from call once.
The review can be found here: http://reviews.llvm.org/D10191
llvm-svn: 239654
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