This is an archive of the discontinued LLVM Phabricator instance.

threading_support: introduce __libcpp_recursive_mutex_t
AbandonedPublic

Authored by compnerd on Jan 2 2017, 11:19 PM.

Details

Summary

Introduce the new __libcpp_recursive_mutex_t which differentiates
between a recursive and non-recursive mutex. This is motivated by
windows, where a much lighter wait alternative exists for non-recursive
locks. On pthreads, the same lock type is available with a different
typename and no static initializer value.

Introduce an internal __libcpp_mutex_reference to provide an
implicitly move constructed with type-erasure to let the condition
variable handling get a type-erased discriminated-union which we can
handle appropriately.

Diff Detail

Repository
rL LLVM

Event Timeline

compnerd updated this revision to Diff 82844.Jan 2 2017, 11:19 PM
compnerd retitled this revision from to threading_support: introduce __libcpp_recursive_mutex_t.
compnerd updated this object.
compnerd added reviewers: EricWF, mclow.lists.
compnerd set the repository for this revision to rL LLVM.
compnerd updated this revision to Diff 82845.Jan 2 2017, 11:23 PM

add more context

alexander-shaposhnikov added inline comments.
include/__threading_support
99

indentation looks a bit strange

EricWF added inline comments.Jan 3 2017, 12:30 AM
include/__threading_support
96

This uses C++11 features but is limited to C++03.

108

Wouldn't a static_cast be valid here?

127

This uses C++11 features but is limited to C++03. Although we can technically cheat and use Clang extended rvalue references here.

129

Won't we ever want to pass an lvalue here?

Is __libcpp_mutex_reference all that useful? There is no real dynamism for these mutexes. I'd just add functions for the recursive locks just like we have a separate function for __libcpp_recursive_mutex_init

The dynamic behavior only is used for Windows, not pthreads. So, we dont see it here, but it becomes apparent in the windows support. I was trying to minimize the changes to libc++ itself to avoid having it to consider the recursive vs non-recursive cases. If the libc++ maintainers would prefer to expand the interfaces rather than use the dynamic behavior, Im fine with that approach too.

The dynamic behavior only is used for Windows, not pthreads. So, we dont see it here, but it becomes apparent in the windows support. I was trying to minimize the changes to libc++ itself to avoid having it to consider the recursive vs non-recursive cases. If the libc++ maintainers would prefer to expand the interfaces rather than use the dynamic behavior, Im fine with that approach too.

Another argument that I forgot to mention: __libcpp_condvar_wait and __libcpp_condvar_timedwait are only expected to work with non-recursive mutexes. I feel that this overwidens the API surface. Flattening it out removes the dynamic behavior and makes it clear what operations needs to support what types of mutexes.

compnerd marked 3 inline comments as done.Jan 3 2017, 5:40 PM
compnerd added inline comments.
include/__threading_support
108

Yeah.

127

Switched to pass-by-value.

129

Just changed it to a pass-by-value, which is a l-value.

compnerd updated this revision to Diff 82983.Jan 3 2017, 5:46 PM
compnerd marked 3 inline comments as done.

Use l-values, static_cast.

Im not tied to this approach. I really want to get @mclow.lists or @EricWF to weigh in as to which approach they prefer (new interfaces or the wrapper, or even a new approach).

EricWF edited edge metadata.Jan 4 2017, 12:17 PM

Yeah, I think I agree with @majnemer that I would rather use an expanded interface than this type-erased mutex type. Thank you for working on this.