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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
