Bug in std:shared_mutex on Windows

• cpp-docs

  12 1,477 9.9 PowerShell

  C++ Documentation

  

  It looks like it was declared in Nov 21, and in May 23 they merged in the "fix" by adding "it's approximate" to the docs ( https://github.com/MicrosoftDocs/cpp-docs/commit/447b5d8a781... ), so not sure this is the best approach for actual bugs.

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

• emails

  5 229 7.1 Perl

  emails I received

  Unfortunately, the opposite of that is everybody trying to file random things that aren't actionable. See the collection of mail sent to the curl maintainer…

  https://github.com/bagder/emails/blob/main/2015/2015-06-08.m...

• boto3

  39 9,136 9.7 Python

  AWS SDK for Python

  

  Former AWS here.

  My literal job for the last part of my time at AWS was "help triage bugs in the AWS SDK." This is by far the best repro I've ever seen for such an in-depth event.

  Most of the tickets you get in open ticket trackers are incomplete [ https://github.com/boto/boto3/issues/4011 ] nonsensical [ https://github.com/boto/boto3/issues/4018 ] or weird [ https://github.com/boto/boto3/issues/358 ].

• SRW_ALT

  1 4 5.9 C++

  several years ago i do own implementation of SRW/PushLocks - of course based on original NeillC code..

  https://github.com/rbmm/SRW_ALT/tree/main/PushLock-ALT

  they have slightly worse performance compared to MS, when high contention, and use LIFO acquire logic, but in test with this OP case - work well. in my test i not found bugs in implementation, but of course can not be sure that they not exist, very complex logic really. nodody test this, however very simply replace SRW calls to my implementation, by macros in h file

• SRW-2

  1 3 5.7 C++

  shared to exclusive

  https://github.com/rbmm/SRW-2 - possible better repro code . where i guarantee repro this without hundreds loops. i be say that "question" in RtlReleaseSRWLockExclusive implementation. it first remove Lock bit from SRW (and after this any thread can enter to lock) and then call RtlpWakeSRWLock. but this 2 operations not atomic. if in the middle (after Lock Bit removed and before RtlpWakeSRWLock executed) another thread acquire shared access - it got exclusive. and RtlpWakeSRWLock also "fail" after this - not wake any waiters. but when shared/exlusive owner then release lock..RtlpWakeSRWLock will be called again and self job. i be of course use bit another implementation, link to which i paste in another comment here

• PushLock

  1 3 5.9 C++

  Lock Tests

  https://www.reddit.com/r/cpp/comments/1b55686/comment/ktfggu...

  if say true - i here in very strange position. i am by self under debugger research exacly what happens in concrete case and create repro code. i think that implementation of the RtlReleaseSRWLockExclusive is not the best and may be really containing "bug" as i in more details describe in comment on reddit. but from another side, if you want pure formal c++ rules - can you explain - in what exactly was bug in concre case ? what rule/guarantee is violated ? why demo code decide that ALL shared waiters can at once acquire the lock. formal documentation not state this. this intuitive must be true, because no exclusive request more. but.. i really dont know. and i also for fun create own implementation of SRW lock ( if someone interested to look -https://github.com/rbmm/PushLock ) which free from this roblem - i always ( hope) do only single atomic change to lock state during api call. and finally - sorry for my english and too long answer

Suggest a related project