update guide and readme

Author: ibraheemdev

README.md

@@ -4,46 +4,51 @@
 [<img alt="github" src="https://img.shields.io/badge/github-seize-blue?style=for-the-badge" height="25">](https://github.com/ibraheemdev/seize)
 [<img alt="docs.rs" src="https://img.shields.io/docsrs/seize?style=for-the-badge" height="25">](https://docs.rs/seize)
 
-Fast, efficient, and robust memory reclamation for concurrent data structures.
+Fast, efficient, and predictable memory reclamation for concurrent data
+structures.
 
-See the [quick-start guide] to get started.
+Refer to the [quick-start guide] to get started.
 
 ## Background
 
 Concurrent data structures are faced with the problem of deciding when it is
-safe to free memory. Although an object might have been logically removed, other
-threads that previously loaded it may still be accessing it, and thus it is
+safe to free memory. Despite an object being logically removed, it may still be
+accessible by other threads that are holding references to it, and thus it is
 not safe to free immediately. Over the years, many algorithms have been devised
 to solve this problem. However, most traditional memory reclamation schemes make
-the tradeoff between performance, efficiency, and robustness. For example,
-[epoch based reclamation] is fast and lightweight but lacks robustness in that a
-stalled thread can prevent the reclamation of _all_ retired objects. [Hazard
-pointers], another popular scheme, tracks individual pointers, making it efficient
-and robust but generally much slower.
+a tradeoff between performance and efficiency.
 
-Another problem that is often not considered is workload balancing. In most
-reclamation schemes, the thread that retires an object is the one that reclaims
-it. This leads to unbalanced reclamation in read-dominated workloads; parallelism
-is reduced when only a fraction of threads are writing, degrading memory efficiency.
+For example, [hazard pointers] track individual pointers, making them very
+memory efficient but also relatively slow. On the other hand, [epoch based
+reclamation] is fast and lightweight, but lacks predictability, requiring
+periodic checks to determine when it is safe to free memory. This can cause
+reclamation to trigger unpredictably, leading to poor latency distributions.
 
-## Implementation
+Alternative epoch-based schemes forgo workload balancing, relying on the thread
+that retires an object always being the one that frees it. While this can avoid
+synchronization costs, it also leads to unbalanced reclamation in read-dominated
+workloads; parallelism is reduced when only a fraction of threads are writing,
+degrading memory efficiency as well as performance.
 
-seize is based on the [hyaline reclamation scheme], which uses reference counting
-to determine when it is safe to free memory. However, reference counters are only
-used for already retired objects, allowing it to avoid the high overhead incurred
-by traditional reference counting schemes where every memory access requires modifying
-shared memory. Reclamation is naturally balanced as the thread with the last reference
-to an object is the one that frees it. This removes the need to check whether other
-threads have made progress, leading to predictable latency without sacrificing performance.
-Epochs can also be tracked to protect against stalled threads, making reclamation truly
-lock-free.
+## Implementation
 
-seize provides performance competitive with that of epoch based schemes, while memory efficiency
-is similar to that of hazard pointers. seize is compatible with all modern hardware that
-supports single-word atomic operations such as FAA and CAS.
+`seize` is based on the [hyaline reclamation scheme], which uses reference
+counting to determine when it is safe to free memory. However, unlike
+traditional reference counting schemes where every memory access requires
+modifying shared memory, reference counters are only used for retired objects.
+When a batch of objects is retired, a reference counter is initialized and
+propagated to all active threads. Threads cooperate to decrement the reference
+counter as they exit, eventually freeing the batch. Reclamation is naturally
+balanced as the thread with the last reference to an object is the one that
+frees it. This also removes the need to check whether other threads have made
+progress, leading to predictable latency without sacrificing performance.
+
+`seize` provides performance competitive with that of epoch based schemes, while
+memory efficiency is similar to that of hazard pointers. `seize` is compatible
+with all modern hardware that supports single-word atomic operations such as FAA
+and CAS.
 
 [quick-start guide]: https://docs.rs/seize/latest/seize/guide/index.html
-[tokio]: https://github.com/tokio-rs/tokio
 [hazard pointers]:
   https://www.cs.otago.ac.nz/cosc440/readings/hazard-pointers.pdf
 [hyaline reclamation scheme]: https://arxiv.org/pdf/1905.07903.pdf

benches/stack.rs

@@ -138,8 +138,7 @@ mod seize_stack {
         }
 
         fn is_empty(&self) -> bool {
-            let guard = self.collector.enter();
-            guard.protect(&self.head, Ordering::Relaxed).is_null()
+            self.head.load(Ordering::Relaxed).is_null()
         }
     }