Sujet : Re: Is Intel exceptionally unsuccessful as an architecture designer?
De : jseigh_es00 (at) *nospam* xemaps.com (jseigh)
Groupes : comp.archDate : 03. Oct 2024, 15:25:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vdm9gn$3oluc$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
User-Agent : Mozilla Thunderbird
On 10/2/24 20:34, Lawrence D'Oliveiro wrote:
On Tue, 24 Sep 2024 07:50:36 +0200, Terje Mathisen wrote:
Somebody wiser than me had written something like "You cannot
write/test/debug multithreaded programs without the ability for multiple
threads to actually run at the same time."
Some threading bugs will more likely show up in multiple-CPU situations,
others will more likely show up in single-CPU situations. You need to test
every which way you can.
The 1990s were a “let’s use threads for everything” time. Thankfully, we
have become a bit more restrained since then ...
Some things you can't test for. For example, hazard pointers without
the store/load memory barrier. You need an asymmetric memory barrier
for the memory reclamation thread to use. But the timing window that
a race condition can happen if you didn't use that asymmetric memory
barrier in is too small for any bad things to happen. You might
think, oh if preemption occurred in the middle of a
hazard pointer load, that would increase the timing window but
guess what, that interrupt that caused the preemption effected a
memory barrier. I did get around to showing formally that a
false negative, which might make you think it was safe to reclaim
the memory, when it was in fact not safe, cannot occur.
Joe Seigh