Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c++
Subject: Re: Solving thundering Herd with glibc...
Date: Fri, 16 May 2025 15:33:10 +0200
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <1007eqm$3penh$2@dont-email.me>
References: <vue7i0$2btp7$1@dont-email.me>
 <vue9bf$2dodm$2@raubtier-asyl.eternal-september.org>
 <vueanl$2erl6$1@dont-email.me>
 <vufhi7$3jcg6$1@raubtier-asyl.eternal-september.org>
 <1002beu$2htkv$2@dont-email.me> <10042po$306q5$1@dont-email.me>
 <slrn102ebqi.3gnpo.candycanearter07@candydeb.host.invalid>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 May 2025 15:33:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="73d891a72f05717b4fcf9043c40a17ba";
	logging-data="3980017"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18zGTxk/ozVFnV1vvI8y/U7GRft9LSvZd4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:C6uD62t3jZCI2Seo+79yZJd/chc=
Content-Language: en-GB
In-Reply-To: <slrn102ebqi.3gnpo.candycanearter07@candydeb.host.invalid>

On 16/05/2025 14:30, candycanearter07 wrote:
> David Brown <david.brown@hesbynett.no> 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.)