xnotify.cpp: SRWLOCK to protect the at-thread-exit data instead of an indexed CRITICAL_SECTION
#4408
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
StephanTLavavej
changed the title
xnotify.cpp: SRWLOCK to protect the new handler instead of an indexed CRITICAL_SECTIONxnotify.cpp: SRWLOCK to protect the at-thread-exit data instead of an indexed CRITICAL_SECTION
|
Fixed copy-pasted title. |
| @@ -13,7 +13,7 @@ | |||
|
|
|||
| _STD_BEGIN | |||
|
|
|||
| constexpr int _Max_lock = 8; // must be power of two | |||
| constexpr int _Max_lock = 8; // must be power of two; TRANSITION, ABI: may be less now | |||
There was a problem hiding this comment.
No change requested: It would actually be ABI-safe to reduce _Max_lock to 4, assuming that nobody external was ever hijacking our internal APIs for their own nefarious purposes. I might do this in a followup PR. I noticed it too late to update this comment and it's not worth resetting testing.
(The remaining _LOCK_LOCALE, _LOCK_STREAM, and _LOCK_DEBUG constants must remain unchanged so that old-compiled code and new-compiled code can agree on what they're locking. We're just fortunate that they all happened to be less than 4.)
There was a problem hiding this comment.
I don't know. As vNext is clearly not happening soon, we might want to keep some mutexes around for C++26 features or whatever.
|
I've pushed a merge with |
|
Thanks for finding a nice way to clean up this old code! 🧹 🚀 😻 |
Towards #3521. Fixes #273.
After finally making mutex constructor and destructor constexpr, it is time that we start using usual mutexes!