Doxygen doc updates

git-svn-id: http://svn.digium.com/svn/asterisk/trunk@16551 f38db490-d61c-443f-a65b-d21fe96a405b

1 files changed, 7 insertions, 3 deletions

diff --git a/include/asterisk/lock.h b/include/asterisk/lock.h
index 77b32327c..7c144a657 100644
--- a/include/asterisk/lock.h
+++ b/include/asterisk/lock.h
@@ -19,24 +19,28 @@
 /*! \file
  * \brief General Asterisk channel locking definitions.
  *
+ * - See \ref LockDef
+ */
+/* \page LockDef Asterisk thread locking models
+ *
  * This file provides several different implementation of the functions,
  * depending on the platform, the use of DEBUG_THREADS, and the way
  * global mutexes are initialized.
  * At the moment, we have 3 ways to initialize global mutexes, depending on
  *
- *  + static: the mutex is assigned the value AST_MUTEX_INIT_VALUE
+ *  - \b static: the mutex is assigned the value AST_MUTEX_INIT_VALUE
  *        this is done at compile time, and is the way used on Linux.
  *        This method is not applicable to all platforms e.g. when the
  *        initialization needs that some code is run.
  *
- *  + on first use: the mutex is assigned a magic value at compile time,
+ *  - \b on first use: the mutex is assigned a magic value at compile time,
  *        and ast_mutex_init() is called when this magic value is detected.
  *        This technique is generally applicable, though it has a bit of
  *        overhead on each access to check whether initialization is needed.
  *        On the other hand, the overall cost of a mutex_lock operation
  *        is such that this overhead is often negligible.
 
- *  + through constructors: for each mutex, a constructor function is
+ *  - \b through constructors: for each mutex, a constructor function is
  *        defined, which then runs when the program (or the module)
  *        starts. The problem with this approach is that there is a
  *        lot of code duplication (a new block of code is created for