Hacker News Reader

Comment by wubrr | Hacker News Reader

Every place I worked at, that had any kind of reliable, high-throughput concurrent system had an extensive suite of concurrent tests.

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

View on HN

> 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.

Did you Google “concurrency testing” and send me the top 5 results?

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).

> In Go 1.24, we are introducing a new, experimental testing/synctest package Clearly a mature mechanism we'd see in large companies...

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.

They said twenty, not 76000. What a crock.

same thing

Perhaps he had a concurrency bug writing the sentence and didn't lock the value

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.

Reply on news.ycombinator.com