[PATCH] D21637: [libcxx] Don't use pthread initializers in constexpr constructors
Asiri Rathnayake via cfe-commits
cfe-commits at lists.llvm.org
Thu Jun 30 04:08:09 PDT 2016
rmaprath added a comment.
In http://reviews.llvm.org/D21637#471154, @EricWF wrote:
> In http://reviews.llvm.org/D21637#471151, @rmaprath wrote:
>
> > Small side question: so how are `__m_` and `__cv_` initialized in this setup? is it that `pthread_mutex_lock()` and the like would be able to handle an un-initialized blob of memory (in a thread-safe way)? Because I don't see a call to `pthread_mutex_init()` anywhere in the code-path.
>
>
> `__m_` and `__cv_` are initialized during non-static data member initialization. They didn't previously call pthread_mutex_lock(), instead they directly initialized '__m_' and '__cv_' in the constructors initializer list.
>
> And according to the current spec we are allowed to use PTHREAD_MUTEX_INITIALIZER to initialize non-static mutexes.
> http://pubs.opengroup.org/onlinepubs/9699919799/
>
> > In cases where default mutex attributes are appropriate, the macro PTHREAD_MUTEX_INITIALIZER can be used to initialize mutexes.
>
> > The effect shall be equivalent to dynamic initialization by a call to pthread_mutex_init() with parameter attr specified as NULL, except that no error checks are performed.
>
Ah! I've misread the patch - missed the assignment in the constructor (for the `_LIBCPP_HAS_NO_CONSTEXPR` case). Sorted now.
Thanks.
/ Asiri
http://reviews.llvm.org/D21637
More information about the cfe-commits
mailing list