Docfix

[libcds.git] / cds / intrusive / details / base.h

diff --git a/cds/intrusive/details/base.h b/cds/intrusive/details/base.h
index 331e3b7c50ee1a50fa2b5782a751192db1540e47..511896799463429b4219a168c4d3f755af408b4f 100644 (file)
--- a/cds/intrusive/details/base.h
+++ b/cds/intrusive/details/base.h
@@ -40,12 +40,12 @@ namespace cds {
 /// Intrusive containers
 /**
     @ingroup cds_intrusive_containers
-    The namespace cds::intrusive contains intrusive lock-free containers.
+    The namespace \p cds::intrusive contains intrusive lock-free containers.
     The idea comes from \p boost::intrusive library, see http://boost.org/doc/ as a good introduction to intrusive approach.
     The intrusive containers of libcds library is developed as close to \p boost::intrusive
 
     In terms of lock-free approach, the main advantage of intrusive containers is
-    that no memory allocation is performed to maintain container items.
+    that no memory allocation is performed to maintain container elements.
     However, additional requirements are imposed for types and values that can be stored in intrusive container.
     See the container documentation for details.
 
@@ -282,15 +282,15 @@ namespace cds {
     If you develop your intrusive container based on <b>libcds</b> library framework, you should
     take in the account the following.
     The main idea of garbage collectors (GC) based on Hazard Pointer schema is protecting a shared pointer
-    by publishing it as a "hazard" one i.e. as a pointer that is changing at the current time and cannot be
-    deleted at this moment. In intrusive container paradigm, the pointer to the node of the container
-    and the pointer to the item stored in the container are not equal in the general case.
-    However, any pointer to the node should be castable to the appropriate pointer to the container's item.
-    In general, any item can be placed to some different intrusive containers simultaneously,
-    and each of those container holds a unique pointer to its node that refers to the same item.
+    by publishing it as a "hazard" i.e. as a pointer that is changing at the current time and cannot be
+    deleted at this moment. In intrusive container paradigm, the pointer to a node of the container
+    and the pointer to a item stored in the container are not equal in the general case.
+    However, any pointer to node should be castable to appropriate pointer to container's item.
+    In general, any item can be placed to two or more intrusive containers simultaneously,
+    and each of those container holds an unique pointer to its node that refers to the same item.
     When we protect a pointer, we want to protect an <b>item</b> pointer that is the invariant
-    for any container stored that item. In your intrusive container, instead of protecting by GC's guard a pointer to an node
-    you should convert it to the pointer to the item and then protect resulting item pointer.
+    for any container stored that item. In your intrusive container, instead of protecting by GC's guard a pointer to node
+    you should cast it to the pointer to item and then protect that item pointer.
     Otherwise an unpredictable result may occur.
 */
 namespace intrusive {