X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=cds%2Fsync%2Fmonitor.h;h=2ac85a330b2140cd9e371dddafe18c397fc8f7a9;hb=99d4d70957c586988f4a15e5f0f7df511086c2d8;hp=09eb1970a185dac768d29882916f4e216749df41;hpb=d058aaf673e0862f518eb80135de41c6a724d66c;p=libcds.git

diff --git a/cds/sync/monitor.h b/cds/sync/monitor.h
index 09eb1970..2ac85a33 100644
--- a/cds/sync/monitor.h
+++ b/cds/sync/monitor.h
@@ -1,7 +1,10 @@
 //$$CDS-header$$
+
 #ifndef CDSLIB_SYNC_MONITOR_H
 #define CDSLIB_SYNC_MONITOR_H
+
 #include <cds/details/defs.h>
+
 namespace cds { namespace sync {
     /**
         @page cds_sync_monitor Synchronization monitor
@@ -16,7 +19,9 @@ namespace cds { namespace sync {
         lock object for the node if needed, and to lock the node.
         The monitor strategy can significantly reduce the number of system objects
         required for data structure.
+
         <b>Implemetations</b>
+
         \p libcds contains several monitor implementations:
         - \p sync::injecting_monitor injects the lock object into each node.
             That mock monitor is designed for user-space locking primitive like
@@ -25,11 +30,14 @@ namespace cds { namespace sync {
             for a node from the pool when needed. When the node is unlocked
             the lock assigned to it is given back to the pool if no thread
             references to that node.
+
         <b>How to use</b>
+
         If you use a container from \p libcds that requires a monitor, you should just
         specify required monitor type in container's traits. Usually, the monitor
         is specified by \p traits::sync_monitor typedef, or by \p cds::opt::sync_monitor
         option for container's \p make_traits metafunction.
+
         If you're developing a new container algorithm, you should know internal monitor
         interface:
         \code