Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: candycanearter07 Newsgroups: comp.lang.c++ Subject: Re: Solving thundering Herd with glibc... Date: Sun, 18 May 2025 19:20:05 -0000 (UTC) Organization: the-candyden-of-code Lines: 42 Message-ID: References: <1002beu$2htkv$2@dont-email.me> <10042po$306q5$1@dont-email.me> <1007eqm$3penh$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 18 May 2025 21:20:05 +0200 (CEST) Injection-Info: dont-email.me; posting-host="dca6fc73c19334029b9e35e1ceaf825b"; logging-data="1217634"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ci5blFjy7EjXWHQMKhE33tEFD1v2PNjDOiZnkkRrvdg==" User-Agent: slrn/1.0.3 (Linux) Cancel-Lock: sha1:1LiZcmaqxaHHXnrLzAmOLfFtdSA= X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]% b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e ZrQsWJ >|l^I_[pbsIqwoz.WGA] wrote at 13:33 this Friday (GMT): > On 16/05/2025 14:30, candycanearter07 wrote: >> David Brown 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: >>>>> >>>>>> "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. >>>>> >>>> Once upon a time I put a race in a bit of code. >>>> >>>> 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.) Ah, fair enough. -- user is generated from /dev/urandom