smeenai added inline comments.
================ Comment at: include/__threading_support:300-305 +int __libcpp_recursive_mutex_init(__libcpp_mutex_t *__m) +{ + InitializeSRWLock(__m); + return 0; +} + ---------------- majnemer wrote: > compnerd wrote: > > majnemer wrote: > > > I don't think you can use slim rw locks for recursive locks. I think we > > > will need to use `CRITICAL_SECTION` for those. std::recursive_mutex can't > > > be used with std::condition_variable AFAIK so all you need (I think) is > > > recursive versions of `__libcpp_mutex_...` > > > > > > Recursive locks should be used far less frequently which makes it > > > valuable, IMO, to use slim rw locks for the non-recursive mutex > > > implementation. > > You are absolutely right. That was something that I looked at originally > > and went with the CS. However, the overhead of a tagged struct is 5 or 9 > > bytes (sizeof(void *) + 1) bytes (ignoring padding for MS ABI). Going with > > that should give the benefits of always being able to properly initialize > > the CS instead of the kludge. > Er, isn't the overhead much more than that? IIRC, `CRITICAL_SECTION` is quite > large. You'd be making all the users of `std::mutex` pay for the space of > `std::recursive_mutex`... Yeah, CRITICAL_SECTION is 24 bytes vs 4 bytes for a SRWLOCK. Repository: rL LLVM https://reviews.llvm.org/D28220 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits