[cpp.predefined]p2:
__STDCPP_THREADS__
Defined, and has the value integer literal 1, if and only if a program
can have more than one thread of execution .
Also define it only if it's not defined already, since it's supposed
to be defined by the compiler.
Also move it from thread to __config (which requires setting it only
if _LIBCPP_HAS_NO_THREADS is not defined).
Part of PR33230. The intent is to eventually make the compiler define
this instead.
llvm-svn: 367316
Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.
The constexpr constructor is required to ensure the construction of a
mutex with static storage duration happens at compile time, during
constant initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used
safely during dynamic initialization without the "static initialization
order fiasco".
A trivial destructor is important for similar reasons. If a mutex is
used during dynamic initialization it might also be used during program
termination. If a static mutex has a non-trivial destructor it will be
invoked during termination. This can introduce the "static
deinitialization order fiasco".
Additionally, function-local statics emit a guard variable around
non-trivially destructible types. This results in horrible codegen and
adds a runtime cost to every call to that function. non-local static's
also result in slightly worse codegen but it's not as big of a problem.
Example codegen can be found here: https://goo.gl/3CSzbM
Note: This optimization is not safe with every pthread implementation.
Some implementations allocate on the first call to pthread_mutex_lock
and free the allocation in pthread_mutex_destroy.
Also, changing the triviality of the destructor is not an ABI break.
At least to the best of my knowledge :-)
llvm-svn: 365273
Drive-by:
* Fix potential race between check and update of `throw_one` in `operator new`
* Fix latent bug in `operator delete`, which shouldn't decrement `outstanding_new` when passed a null pointer
* Specifically catch the expected `bad_alloc` in `main` instead of `...`
Differential Revision: https://reviews.llvm.org/D50860
llvm-svn: 359827
Some tests #include <iostream> but they don't use anything from the
header. Those are probably artifacts of when the tests were developped.
llvm-svn: 357181
Dylib support for shared_mutex was added in macOS 10.12, so the tests
should be XFAILed accordingly instead of being completely disabled
whenever availability is enabled.
rdar://problem/48769104
llvm-svn: 357079
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
The test was previously marked as unsupported on all Apple platforms, when
we really just want to mark it as unsupported for previously shipped dylibs
on macosx.
llvm-svn: 347920
In this example, the ctor of G runs in the main thread in the expression G(), and also in the copy ctor of G() in the DECAY_COPY inside std::thread. The main thread destroys the G() instance at the semicolon, and the started thread destroys the G() after it returns. Thus there is a race between the threads on the n_alive variable.
The fix is to join with the background thread before attempting to destroy the G in the main thread.
llvm-svn: 344820
PR38682 added a test to check for a race condition in std::future.
Part of the fix is part of the dylib, but there is no released version
of mac OS X that ships a dylib containing the fix. Hence, this test can
(and sometimes does) when testing on OS X. This commit marks the test
as unsupported to avoid spurious failures.
llvm-svn: 344053
Summary:
The state associated to the future was set in one thread (with synchronization)
but read in another thread without synchronization, which led to a data race.
https://bugs.llvm.org/show_bug.cgi?id=38181
rdar://problem/42548261
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51170
llvm-svn: 340608
test/std/containers/Emplaceable.h
test/std/containers/NotConstructible.h
test/support/counting_predicates.hpp
Replace unary_function/binary_function inheritance with typedefs.
test/std/depr/depr.function.objects/depr.base/binary_function.pass.cpp
test/std/depr/depr.function.objects/depr.base/unary_function.pass.cpp
test/std/utilities/function.objects/func.require/binary_function.pass.cpp
test/std/utilities/function.objects/func.require/unary_function.pass.cpp
Mark these tests as requiring 98/03/11/14 because 17 removed unary_function/binary_function.
test/std/thread/futures/futures.task/futures.task.members/ctor_func_alloc.pass.cpp
test/std/thread/futures/futures.task/futures.task.nonmembers/uses_allocator.pass.cpp
Mark these tests as requiring 11/14 because 17 removed packaged_task allocator support.
test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp
This test doesn't need to be skipped in C++17 mode. Only the construction of
std::function from an allocator needs to be skipped in C++17 mode.
test/std/utilities/function.objects/refwrap/refwrap.access/conversion.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.assign/copy_assign.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.const/copy_ctor.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.pass.cpp
When testing these reference_wrapper features, unary_function inheritance is totally irrelevant.
test/std/utilities/function.objects/refwrap/weak_result.pass.cpp
Define and use my_unary_function/my_binary_function to test the weak result type machinery
(which is still present in C++17, although deprecated).
test/support/msvc_stdlib_force_include.hpp
Now we can test C++17 strictly, without enabling removed features.
Fixes D36503.
llvm-svn: 311705
On Bionic PTHREAD_MUTEX_INITIALIZER contains the expression "<enum-type> & <integer-type>",
which causes ADL to perform name lookup for operator&. During this lookup Clang decides
that it requires the default member initializer for std::mutex while defining the DMI
for std::mutex::__m_.
If I'm not mistaken this is caused by the explicit noexcept declaration on the defaulted
constructor.
This patch removes the explicit noexcept and instead allows the compiler to declare
the default constructor implicitly noexcept. It also adds a static_assert to ensure
that happens.
Unfortunatly because it's not easy to change the value of _LIBCPP_MUTEX_INITIALIZER
for a single test there is no good way to test this patch.
The Clang behavior causing the trouble here was introduced in r287713, which first
appears in the 4.0 release.
llvm-svn: 304942
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.
See docs/DesignDocs/AvailabilityMarkup.rst for more information.
Differential Revision: https://reviews.llvm.org/D31739
llvm-svn: 302172
r300140 introduced a bunch of failures by changing the internal
interface provided by __compressed_pair. This patch fixes all of
the failures caused by the new interface by changing the existing
code to use it.
In addition to those changes this patch also fixes two separate
issues causing test failures:
1) Fix the member swap definition for __map_value_compare. Previously
the swap was incorrectly configured to swap the comparator as const.
2) Fix an assertion failure in futures.task.members/ctor_func_alloc.pass.cpp
that incorrectly expected a move to take place when a single copy is sufficient.
There is one remaining failure regarding make_shared. I'll commit a fix for that
shortly.
llvm-svn: 300148
The tests for libc++ specify -target on the command-line to the
compiler, but this is problematic for a few reasons.
Firstly, the -target option isn't supported on Apple platforms. Parts
of the triple get dropped and ignored. Instead, software should be
compiled with a combination of the -arch and -m<name>-version-min
options.
Secondly, the generic "darwin" target references a kernel version
instead of a platform version. Each platform has its own independent
versions (with different versions of libc++.1.dylib), independent of the
version of the Darwin kernel.
This commit adds support to the LIT infrastructure for testing against
Apple platforms using -arch and -platform options.
If the host is not on OS X, or the compiler type is not clang or apple-clang, then this commit has NFC.
If the host is on OS X and --param=target_triple=... is specified, then a warning is emitted to use arch and platform instead. Besides the warning, there's NFC.
If the host is on OS X and *no* target-triple is specified, then use the new deployment target logic. This uses two new lit parameters, --param=arch=<arch> and --param=platform=<platform>. <platform> has the form <name>[<version>].
By default, arch is auto-detected from clang -dumpmachine, and platform is "macosx".
If the platform doesn't have a version:
For "macosx", the version is auto-detected from the host system using sw_vers. This may give a different version than the SDK, since new SDKs can be installed on older hosts.
Otherwise, the version is auto-detected from the SDK version using xcrun --show-sdk-path.
-arch <arch> -m<name>-version-min=<version> is added to the compiler flags.
The target triple is computed as <arch>-apple-<platform>. It is *not* passed to clang, but it is available for XFAIL and UNSUPPORTED (as is with_system_cxx_lib=<target>).
For convenience, apple-darwin and <arch>-apple-darwin are added to the set of available features.
There were a number of tests marked to XFAIL on x86_64-apple-darwin11
and x86_64-apple-darwin12. I updated these to
x86_64-apple-macosx10.7 and x86_64-apple-macosx10.8.
llvm-svn: 297798
This test explicitly is checking the behaviour of std::thread and
pthread interactions. This requires pthreads. Add an appropriate
requirement.
llvm-svn: 294903
Summary:
Exactly what the title says.
This patch also adds a `std::hash<nullptr_t>` specialization in C++17, but it was not added by this paper and I can't find the actual paper that adds it.
See http://wg21.link/P0513R0 for more info.
If there are no comments in the next couple of days I'll commit this
Reviewers: mclow.lists, K-ballo, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28938
llvm-svn: 292684
The destructor of std::promise needs to construct a std::future_error
exception so it calls std::make_exception_ptr. But under
libcpp-no-exceptions this will trigger an abort.
Differential Revision: https://reviews.llvm.org/D27614
llvm-svn: 291550
This patch overhalls the libc++ test format/configuration in order to fully support modules. By "fully support" I mean get almost all of the tests passing. The main hurdle for doing this is handling tests that `#define _LIBCPP_FOO` macros to test a different configuration. This patch deals with these tests in the following ways:
1. For tests that define single `_LIBCPP_ABI_FOO` macros have been annotated with `// MODULES_DEFINES: _LIBCPP_ABI_FOO`. This allows the test suite to define the macro on the command line so it uses a different set of modules.
2. Tests for libc++'s debug mode (which define custom `_LIBCPP_ASSERT`) are automatically detected by the test suite and are compiled and run with modules disabled.
This patch also cleans up how the `CXXCompiler` helper class handles enabling/disabling language features.
NOTE: This patch uses `LIT` features which were only committed to LLVM today. If this patch breaks running the libc++ tests you probably need to update LLVM.
llvm-svn: 288728
test/std/depr/depr.c.headers/inttypes_h.pass.cpp
test/std/input.output/file.streams/c.files/cinttypes.pass.cpp
test/std/input.output/iostream.forward/iosfwd.pass.cpp
Add test() to avoid a bunch of void-casts, although we still need a few.
test/std/input.output/iostream.format/quoted.manip/quoted.pass.cpp
skippingws was unused (it's unclear to me whether this was mistakenly copy-pasted from round_trip() below).
test/std/localization/locale.categories/category.collate/locale.collate/types.pass.cpp
test/std/localization/locale.categories/category.ctype/facet.ctype.special/types.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.codecvt/types_char.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.codecvt/types_wchar_t.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.ctype/types.pass.cpp
test/std/localization/locale.categories/facet.numpunct/locale.numpunct/types.pass.cpp
test/std/localization/locales/locale.global.templates/use_facet.pass.cpp
When retrieving facets, the references are unused.
test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long.pass.cpp
test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_unsigned_long.pass.cpp
"std::ios_base::iostate err = ios.goodbit;" was completely unused here.
test/std/localization/locale.categories/category.time/locale.time.get/time_base.pass.cpp
test/std/numerics/c.math/ctgmath.pass.cpp
test/std/numerics/rand/rand.device/entropy.pass.cpp
test/std/numerics/rand/rand.device/eval.pass.cpp
test/std/strings/basic.string/string.modifiers/string_copy/copy.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/eof.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/eof.pass.cpp
test/std/thread/futures/futures.promise/dtor.pass.cpp
test/std/thread/futures/futures.task/futures.task.members/dtor.pass.cpp
test/std/thread/thread.condition/thread.condition.condvar/wait_for_pred.pass.cpp
These variables are verifying types but are otherwise unused.
test/std/strings/basic.string/string.capacity/reserve.pass.cpp
old_cap was unused (it's unclear to me whether it was intended to be used).
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/lt.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/lt.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/lt.pass.cpp
These tests contained unused characters.
llvm-svn: 286847
This is a follow up of D24562.
These tests do not check anything but exceptions, so it makes sense to mark
them as UNSUPPORTED under a library built without exceptions.
Differential Revision: https://reviews.llvm.org/D26075
llvm-svn: 285550
First batch of changes to get some of these XFAILs working in the
no-exceptions libc++ variant.
Changed some XFAILs to UNSUPPORTED where the test is all about exception
handling. In other cases, used the test macros TEST_THROW and
TEST_HAS_NO_EXCEPTIONS to conditionally exclude those parts of the test
that concerns exception handling behaviour.
Reviewers: EricWF, mclow.lists
Differential revision: https://reviews.llvm.org/D24562
llvm-svn: 283441
Summary:
This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`.
Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec:
>
> Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread.
>
> An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.
>
> If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop.
However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit".
Reviewers: mclow.lists, bcraig, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24159
llvm-svn: 280588
Some of the mutex tests fail on machines with high load. This patch implements
the test directive "// FLAKY_TEST" which allows a test to be run 3 times
before it's considered a failure.
llvm-svn: 280050
Summary:
This patch implements the variadic `lock_guard` paper.
Making `lock_guard` variadic is a ABI breaking change because the specialization `lock_guard<_Mutex>` mangles differently then when it was the primary template. This change only provides variadic `lock_guard` in ABI V2 or when `_LIBCPP_ABI_VARIADIC_LOCK_GUARD` is defined.
Note that in ABI V2 `lock_guard` must always be declared as a variadic template, even in C++03, in order to keep the ABI consistent. For this reason `lock_guard` is forward declared as a variadic template in all standard dialects and therefore depends on variadic templates being provided as an extension in C++03. All supported versions of Clang and GCC provide this extension.
Reviewers: mclow.lists
Subscribers: K-ballo, mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D21260
llvm-svn: 272634
This patch addresses the following issues in the test suite:
1. Move "std::bad_array_length" test from std/ to libcxx/ test directory
since the feature is not a part of the standard.
2. Rename "futures.tas" test directory to "futures.task" since that is the
correct stable name.
3. Move tests for "packaged_task<T>::result_type" from std/ to libcxx/
test directory since the typedef is a libc++ extension.
llvm-svn: 271430
Quite a few libcxx tests seem to follow the format:
#if _LIBCPP_STD_VER > X
// Do test.
#else
// Empty test.
#endif
We should instead use the UNSUPPORTED lit directive to exclude the test on
earlier C++ standards. This gives us a more accurate number of test passes
for those standards and avoids unnecessary conflicts with other lit
directives on the same tests.
Reviewers: bcraig, ericwf, mclow.lists
Differential revision: http://reviews.llvm.org/D20730
llvm-svn: 271108
This patch does the following:
* Remove <__config> includes from some container tests.
* Guards uses of std::launch::any in async tests because it's an extension.
* Move "test/std/extensions" to "test/libcxx/extensions"
* Moves various non-standard tests including those in "sequences/vector",
"std/localization" and "utilities/meta".
llvm-svn: 267981
Summary:
Hi,
When creating a new thread libc++ performs at least 2 allocations. The first allocates a tuple of args and the functor that will be passed to the new thread. The second allocation is for the thread local storage needed internally by libc++. Currently the second allocation happens in the child thread, meaning that if it throws the program will terminate with an uncaught bad alloc.
The solution to this is to allocate ALL memory in the parent thread and then pass it to the child.
See https://llvm.org/bugs/show_bug.cgi?id=15638
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13748
llvm-svn: 266851
Fixes a small omission in libcxx that prevents libcxx being built when
-DLIBCXX_ENABLE_EXCEPTIONS=0 is specified.
This patch adds XFAILS to all those tests that are currently failing
on the new -fno-exceptions library variant. Follow-up patches will
update the tests (progressively) to cope with the new library variant.
Change-Id: I4b801bd8d8e4fe7193df9e55f39f1f393a8ba81a
llvm-svn: 252598
After months of work there are only 4 tests still failing in C++03.
This patch fixes those tests.
All of the libc++ builders should be green.
llvm-svn: 246275
Summary:
This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`.
It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header.
@mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03?
Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`.
Reviewers: mclow.lists
Subscribers: vsk, mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D12135
llvm-svn: 246271
First I removed all of the uses of _LIBCPP_STD_VER and added LIT UNSUPPORTED tags to prevent the tests from being run in older standard dialects.
Second I increased the time tolerances used in some tests when testing with Thread Sanitizer because thread sanitizer make these tests take longer.
llvm-svn: 245793
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
Nico Weber