From 6d16ea57a3d34b3627001f2e3b91500c218ee4dc Mon Sep 17 00:00:00 2001 From: SabrinaJewson Date: Fri, 12 Jan 2024 12:24:29 +0000 Subject: [PATCH] =?UTF-8?q?Explain=20the=20terms=20=E2=80=9Cstrongly/weakl?= =?UTF-8?q?y-ordered=20hardware=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/atomics/atomics.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/atomics/atomics.md b/src/atomics/atomics.md index fc3acb4..979f102 100644 --- a/src/atomics/atomics.md +++ b/src/atomics/atomics.md @@ -105,10 +105,12 @@ However there's a third potential state that the hardware enables: * `y = 2`: (thread 2 saw `x = 1`, but not `y = 3`, and then overwrote `y = 3`) It's worth noting that different kinds of CPU provide different guarantees. It -is common to separate hardware into two categories: strongly-ordered and weakly-ordered. -Most notably x86/64 provides strong ordering guarantees, while ARM -provides weak ordering guarantees. This has two consequences for concurrent -programming: +is common to separate hardware into two categories: strongly-ordered and +weakly-ordered, where strongly-ordered hardware implements weak orderings like +`Relaxed` using strong orderings like `Acquire`, while weakly-ordered hardware +makes use of the optimization potential that weak orderings like `Relaxed` give. +Most notably, x86/64 provides strong ordering guarantees, while ARM provides +weak ordering guarantees. This has two consequences for concurrent programming: * Asking for stronger guarantees on strongly-ordered hardware may be cheap or even free because they already provide strong guarantees unconditionally.