> Every place I worked at, that had any kind of reliable, high-throughput concurrent system
Pretty much anyone with high throughput is running a high throughput concurrent system, and very few companies have an extensive suite of concurrency tests unless you just mean load tests (that aren’t setup to catch race conditions).
The “reliable” part of that statement might be doing a lot of heavy lifting depending on what exactly you mean by that.
I gave you several concrete examples. Your claims of 'very few companies have...' aren't very convincing, and the apparent popularity of concurrency testing isn't really a strong argument for or against it's effectiveness or do-ability.
Kind of looks like it … the supporting evidence includes work from Microsoft: learning how to write concurrent programs. Surely not evidence that Microsoft is testing for concurrency bugs (of course they are).
Maybe you should have googled 'concurrency testing' before telling me a story about how you worked at every tech company for 76000 years and never saw any concurrency testing lmao.
Obvious hyperbole aside, I never said "never saw any concurrency testing". I said I never saw a place that was generally and reliably testing for concurrency bugs.
That is to say that following the standard practices at that company, an average developer introducing a concurrency bug will only tend to find out about that bug in production. And even if the developer wants to implement concurrency testing they will probably find it difficult enough to do that they'll give up because it's not a normal part of the test suite.
This is less true for people working on infrastructure like operating systems, and databases than it is for web developers.
https://github.com/postgres/postgres/tree/master/src/test/is...
https://muratbuffalo.blogspot.com/2023/08/distributed-transa...
https://learn.microsoft.com/en-us/archive/msdn-magazine/2008...
https://go.dev/blog/synctest
https://learntla.com/core/concurrency.html