Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug in reader/writer locks in Windows API

old.reddit.com

Post reply on HN
Print view View original

31–40 of 142 posts

Re: Bug in reader/writer locks in Windows API

#31

Post by amluto »

marcosdumay wrote: post #29
amluto wrote: post #9

Once upon a time, you could buy various things from MS that came with support incidents. I had an MSDN subscription that came with two per year. Using an incident got you an actual support engineer who would be helpful and escalate issues if necessary. And, if your issue turned out to be a real bug of any significance in an MS product, your support incident would be credited back. This was great for developers (real…

Well, maybe last century. At any point of this century, the response to those support incidents from MS was always to deny a problem, and if it's a known one, to try to gaslight the customer in a direction contrary to solving it. I have seen organizations lose way too many people-hours trying to satisfy the MS support and apply what it recommended. That when the real solution was often reachable in a hour or two of r…

ISTR a got an actual useful outcome from a support incident related to a bug in the runtime libraries shipped with Visual Studio 2005. Support gave me a hotfix.

Sadly the hotfix had its own little bug: installing it took about 20 hours. Office productivity was rather low for the rest of the day. I don’t know everything that goes on under the hood with Microsoft’s installers, but wow they’re slow.

I, blissfully, don’t use Visual Studio on Windows any more :)

Re: Bug in reader/writer locks in Windows API

#33

Post by tialaramex »

bingo3131 wrote: post #4

Misleading title? This is a Windows API bug with the slim reader/writer (SRW) locks. It's just that the bug was discovered via std::shared_mutex as that is implemented using SRW locks. SRW locks: https://learn.microsoft.com/en-us/windows/win32/sync/slim-re... Confirmation from a Microsoft employee that the bug has been raised internally with the Windows API team: https://old.reddit.com/r/cpp/comments/1b55686/maybe_po…

Yes, for example if you make a Rust std::sync:RWLock on Windows, it will literally be SRWLock because Microsoft advertises this API as having exactly the behaviour Rust wants so why would you build something worse instead ?

Rust's Mutex on Windows is also an SRWLock but it can't hit this bug because it deliberately only uses the exclusive locking.

Re: Bug in reader/writer locks in Windows API

#35

Post by Avamander »

Nition wrote: post #32

> It is extremely difficult for programmer-users to report bugs against the Windows API (we're supposed to direct you to Feedback Hub, but you may as well transmit your message into deep space). :'‑(

This is an issue with a lot of MS products. I honestly have no clue how much money one would have to throw at MS to get a bug fixed.

For example Microsoft's *own* Pluton-enabled platforms fail Windows' Device Health Attestation checks due to an incomplete chain (https://call4cloud.nl/2023/04/are-you-there-intune-its-me-ha...).

Re: Bug in reader/writer locks in Windows API

#36

Post by charcircuit »

jcalvinowens wrote: post #8
mastax wrote: post #2

I understand why this is the case but it’s also extremely frustrating: > It is extremely difficult for programmer-users to report bugs against the Windows API (we're supposed to direct you to Feedback Hub, but you may as well transmit your message into deep space). I've filed OS-49268777 "SRWLOCK can deadlock after an exclusive owner has released ownership and several reader threads are attempting to acquire shared o…

> It is extremely difficult for programmer-users to report bugs against the Windows API I can't imagine living in this hell. When I find bugs in Linux, I E-mail the actual engineers directly and get responses in under 24 hours: https://lore.kernel.org/lkml/Zcb3_fdyJWUlZQci@gmail.com/

Microsoft engineers have emails too.

Re: Bug in reader/writer locks in Windows API

#37

Post by convivialdingo »

AndrewStephens wrote: post #22

Subtle bugs in Reader/Writer locks do not surprise me. I worked on an in-house implementation based on Win32 (before C++11 and std::shared_mutex) and my recollection is that although the implementation sounds simple it is exceedingly easy to make subtle mistakes. The experience left me with such a bad feeling for shared locks that I tend to avoid them unless absolutely required. When I last tested std::shared_mutex,…

I did some work with testing a cross platform in-house library for read-write locking.

We tested cmpxchg16b and found the performance was terrible with more than 4 cores.

Ended up using spin-locks similar to Linux kernel RCU.

Re: Bug in reader/writer locks in Windows API

#38

Post by Avamander »

amluto wrote: post #23
rwmj wrote: post #17

Earlier quoted context omitted.

If it's any consolation, our company pays for 20,000 GMail licenses and we seem unable to escalate any issue at all to Google, even major issues such as their clearly not working spam filtering, emails being lost, incorrect deduplication of emails, or their random IMAP throttling.

Is there any vendor of actually good email-as-a-service? O365/Exchange/Outlook/Hotmail is a mess. Google has a support problem. Fastmail has an offline email problem. iCloud is not obviously suitable for professional use. What’s left?

There are multiple providers out there that have their own stacks (Google, Microsoft, Tutanota, Protonmail to some extent and others) and there are those that use more common combinations (basically just managed mail-in-a-box). Nothing perfect though, so pick your poison.

Some issues are also due to the ecosystem itself. Avoiding POP3 goes a long way for example.

Re: Bug in reader/writer locks in Windows API

#39

Post by tialaramex »

AndrewStephens wrote: post #22

Subtle bugs in Reader/Writer locks do not surprise me. I worked on an in-house implementation based on Win32 (before C++11 and std::shared_mutex) and my recollection is that although the implementation sounds simple it is exceedingly easy to make subtle mistakes. The experience left me with such a bad feeling for shared locks that I tend to avoid them unless absolutely required. When I last tested std::shared_mutex,…

SRWLock seems like a situation where it's small enough for you to construct proofs that what you did is correct, and important enough that the enormous expense of such proof is justified.

The C++ std::mutex provided in Microsoft's STL is ludicrously big, whereas SRWLocks are the same size as a pointer. In one sense being ludicrously big is great - less risk the std::mutex will mistakenly share a cache line with your unrelated data, but for most people this makes std::mutex annoyingly expensive.

Re: Bug in reader/writer locks in Windows API

#40

Post by Nition »

Avamander wrote: post #35
Nition wrote: post #32

> It is extremely difficult for programmer-users to report bugs against the Windows API (we're supposed to direct you to Feedback Hub, but you may as well transmit your message into deep space). :'‑(

This is an issue with a lot of MS products. I honestly have no clue how much money one would have to throw at MS to get a bug fixed. For example Microsoft's *own* Pluton-enabled platforms fail Windows' Device Health Attestation checks due to an incomplete chain ( https://call4cloud.nl/2023/04/are-you-there-intune-its-me-ha... ).

I've noticed a lot of big products have a user feedback cycle that goes something like this:

- Create new feedback tracker

- Direct feedback to tracker

- Stop paying any attention to tracker

- Tracker is hundreds of pages of users shouting into the void, and much of it out-of-date

- Delete everything

- Create new feedback tracker...

Post reply on HN