aboutsummaryrefslogtreecommitdiffhomepage
path: root/content
diff options
context:
space:
mode:
authorJohannes Stoelp <johannes.stoelp@gmail.com>2024-01-29 21:54:05 +0100
committerJohannes Stoelp <johannes.stoelp@gmail.com>2024-01-29 23:49:00 +0100
commit0f44fafa69ec857da37464943bf9fca4212e0617 (patch)
tree8e8f3cc600c39a4d81736c6ed646013f6e41a439 /content
parent778cda58abc61711f054d89b09d8bc016763e774 (diff)
downloadblog-0f44fafa69ec857da37464943bf9fca4212e0617.tar.gz
blog-0f44fafa69ec857da37464943bf9fca4212e0617.zip
cas: fix typo
Diffstat (limited to 'content')
-rw-r--r--content/2023-09-01-cas-llsc-aba/index.md21
1 files changed, 10 insertions, 11 deletions
diff --git a/content/2023-09-01-cas-llsc-aba/index.md b/content/2023-09-01-cas-llsc-aba/index.md
index 177404f..ab7387b 100644
--- a/content/2023-09-01-cas-llsc-aba/index.md
+++ b/content/2023-09-01-cas-llsc-aba/index.md
@@ -13,18 +13,17 @@ different semantics of `atomic` instructions (compare and swap `CAS` vs
load-linked store-conditional `LL/SC`), `lock-free` programming and the `ABA`
problem.
-In the realm of `lock-free` programming and the `ABA` problem, I shared a war
-story from some years ago when I was debugging a random memory corruption in
-our multi-threaded simulator. Sharing that story actually gave the idea to
-write this post as reference for potential new co-workers or all the internet
-people <3.
+In the realm of `lock-free` programming and the `ABA` problem, I shared a story
+from some years ago when I was debugging a random memory corruption in our
+multi-threaded simulator. Sharing that story actually gave the idea to write
+this post as reference for potential new co-workers or all the internet people
+<3.
After many hours of debugging the random memory corruption, which *obviously*
-did not occur very often, it turned out to be a bug in a custom memory
-allocator. To be more precise, in a primitive used by the allocator to manage a
-list of free memory blocks. The allocator was used from multiple threads
-concurrently and hence `pushing` and `popping` free memory blocks had to be
-thread-safe.
+did not occur very often, turned out to be a bug in a custom memory allocator.
+To be more precise, in a primitive used by the allocator to manage a list of
+free memory blocks. The allocator was used from multiple threads concurrently
+and hence `pushing` and `popping` free memory blocks had to be thread-safe.
The operations to manage the free block list were implemented with an
`lock-free` algorithm, which we will visit later when analyzing the bug.
@@ -595,7 +594,7 @@ _exclusive_addr_ and the data to be written with the saved _exclusive_val_.
Iff both compare true, the _store exclusive_ is carried out successfully.
The following pseudo code taken from a comment in
-[QEMU:ranslate-a64.c][qemu-a64-ex] shows how QEMU emits _store exclusive_
+[QEMU:translate-a64.c][qemu-a64-ex] shows how QEMU emits _store exclusive_
instructions where `env` refers to the cpu state.
```c
/// gen_store_exclusive(..)