Am 24.04.2025 um 22:39 schrieb Chris M. Thomasson:
Well, I don't have any more time to mess around with this, but is Bonita
right? does glibc 100% solve _all_ thundering herd problems? I know
about wait morphing, however it is not a 100% solution.
With wait morphing thundering herd is impossible.
Am 24.04.2025 um 23:33 schrieb Chris M. Thomasson:
"there’s no thundering herd, ever!" because a controlled test didn't
"show it" is like saying race conditions do not exist because your
code "worked fine this time."? Fair enough?
Yes, controlled test with 10'000 iterations.
The code is correct and trivial, but too much for you.
On 25/04/2025 09:37, Bonita Montero wrote:
Am 24.04.2025 um 23:33 schrieb Chris M. Thomasson:Once upon a time I put a race in a bit of code.
"there’s no thundering herd, ever!" because a controlled test didn't
"show it" is like saying race conditions do not exist because your
code "worked fine this time."? Fair enough?
Yes, controlled test with 10'000 iterations.
The code is correct and trivial, but too much for you.
It took us 3 years to track down why our customers were reporting
occasional faults :(
(It turned out the trick to reproduce it was a combination of lots of
CPU load and disk transfers not more than once every 30 seconds)
On 14/05/2025 17:05, Vir Campestris wrote:
On 25/04/2025 09:37, Bonita Montero wrote:
Am 24.04.2025 um 23:33 schrieb Chris M. Thomasson:Once upon a time I put a race in a bit of code.
"there’s no thundering herd, ever!" because a controlled test didn't >>>> "show it" is like saying race conditions do not exist because your
code "worked fine this time."? Fair enough?
Yes, controlled test with 10'000 iterations.
The code is correct and trivial, but too much for you.
It took us 3 years to track down why our customers were reporting
occasional faults :(
(It turned out the trick to reproduce it was a combination of lots of
CPU load and disk transfers not more than once every 30 seconds)
It's always fun dealing with a bug that only triggers in rare timing situations. We once had a mistake in a timing table in a program that
could sometimes result in intermittent faults in the system if
particular events occurred at the same time, on the 30th of September. Finding an issue that occurred at most once per year was a challenge!
David Brown <[email protected]> wrote at 06:49 this Thursday (GMT):
On 14/05/2025 17:05, Vir Campestris wrote:
On 25/04/2025 09:37, Bonita Montero wrote:
Am 24.04.2025 um 23:33 schrieb Chris M. Thomasson:Once upon a time I put a race in a bit of code.
"there’s no thundering herd, ever!" because a controlled test didn't >>>>> "show it" is like saying race conditions do not exist because your
code "worked fine this time."? Fair enough?
Yes, controlled test with 10'000 iterations.
The code is correct and trivial, but too much for you.
It took us 3 years to track down why our customers were reporting
occasional faults :(
(It turned out the trick to reproduce it was a combination of lots of
CPU load and disk transfers not more than once every 30 seconds)
It's always fun dealing with a bug that only triggers in rare timing
situations. We once had a mistake in a timing table in a program that
could sometimes result in intermittent faults in the system if
particular events occurred at the same time, on the 30th of September.
Finding an issue that occurred at most once per year was a challenge!
If you knew what date the issue was happening on, could you force the
system clock to be on that day?
On 16/05/2025 14:30, candycanearter07 wrote:
David Brown <[email protected]> wrote at 06:49 this Thursday (GMT): >>> On 14/05/2025 17:05, Vir Campestris wrote:
On 25/04/2025 09:37, Bonita Montero wrote:
Am 24.04.2025 um 23:33 schrieb Chris M. Thomasson:Once upon a time I put a race in a bit of code.
"there’s no thundering herd, ever!" because a controlled test didn't >>>>>> "show it" is like saying race conditions do not exist because your >>>>>> code "worked fine this time."? Fair enough?
Yes, controlled test with 10'000 iterations.
The code is correct and trivial, but too much for you.
It took us 3 years to track down why our customers were reporting
occasional faults :(
(It turned out the trick to reproduce it was a combination of lots of
CPU load and disk transfers not more than once every 30 seconds)
It's always fun dealing with a bug that only triggers in rare timing
situations. We once had a mistake in a timing table in a program that
could sometimes result in intermittent faults in the system if
particular events occurred at the same time, on the 30th of September.
Finding an issue that occurred at most once per year was a challenge!
If you knew what date the issue was happening on, could you force the
system clock to be on that day?
Yes, once we figured out that the issue was date-dependent. For the
first few years, all we knew was that we were getting occasional rare
bug reports and no one saw the coincidence. (This was a program on DOS
- changing the system clock was easy.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 28:36:27 |
| Calls: | 12,107 |
| Calls today: | 7 |
| Files: | 15,006 |
| Messages: | 6,518,234 |