diff options
| -rw-r--r-- | content/2023-09-01-cas-llsc-aba/index.md | 21 |
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(..) |