.

2 files changed, 20 insertions, 18 deletions

diff --git a/ace/Remote_Tokens.cpp b/ace/Remote_Tokens.cpp
index 59e7fbcfad5..928a9b98de3 100644
--- a/ace/Remote_Tokens.cpp
+++ b/ace/Remote_Tokens.cpp
@@ -12,9 +12,9 @@
 ACE_RCSID(ace, Remote_Tokens, "$Id$")
 
 #if defined (ACE_MT_SAFE) && (ACE_MT_SAFE != 0)
-typedef ACE_Thread_Mutex ACE_TSS_CONNECTION_MUTEX;
+#define ACE_TSS_CONNECTION_MUTEX ACE_Thread_Mutex
 #else
-typedef ACE_Null_Mutex ACE_TSS_CONNECTION_MUTEX;
+#define ACE_TSS_CONNECTION_MUTEX ACE_Null_Mutex
 #endif /* ACE_MT_SAFE */
 
 // Make a typedef to simplify access to the Singleton below.
diff --git a/ace/Token.h b/ace/Token.h
index acade74ee1b..40710310973 100644
--- a/ace/Token.h
+++ b/ace/Token.h
@@ -35,27 +35,29 @@ class ACE_Export ACE_Token
 {
   // = TITLE
   //    Class that acquires, renews, and releases a synchronization
-  //    token that is serviced in strict FIFO ordering.
+  //    token that is serviced in strict FIFO ordering and that also
+  //    supports readers/writer semantics.
   //
   // = DESCRIPTION
   //    This class is a more general-purpose synchronization mechanism
   //    than SunOS 5.x mutexes.  For example, it implements "recursive
   //    mutex" semantics, where a thread that owns the token can
-  //    reacquire it without deadlocking.  In addition, threads that are
-  //    blocked awaiting the token are serviced in strict FIFO order as
-  //    other threads release the token (Solaris and Pthread mutexes don't
-  //    strictly enforce an acquisition order).
-  //    There are two FIFO lists within the class.  Write acquires always
-  //    have higher priority over read acquires.  Which means, if you use
-  //    both write/read operations, care must be taken to avoid starvation
-  //    on the readers.  Notice that the read/write acquire operations
-  //    do not have the usual semantic of reader/writer locks.  Only one
-  //    reader can acquire the token at a time (which is different from
-  //    the usual reader/writer locks where several readers can acquire
-  //    a lock at the same time as long as there is no writer waiting for
-  //    the lock.)  We choose the names 1.) to borrow the semantic to give
-  //    writers higher priority, and, 2.) to support a common interface
-  //    over all locking classes in ACE.
+  //    reacquire it without deadlocking.  In addition, threads that
+  //    are blocked awaiting the token are serviced in strict FIFO
+  //    order as other threads release the token (Solaris and Pthread
+  //    mutexes don't strictly enforce an acquisition order).  There
+  //    are two FIFO lists within the class.  Write acquires always
+  //    have higher priority over read acquires.  Which means, if you
+  //    use both write/read operations, care must be taken to avoid
+  //    starvation on the readers.  Notice that the read/write acquire
+  //    operations do not have the usual semantic of reader/writer
+  //    locks.  Only one reader can acquire the token at a time (which
+  //    is different from the usual reader/writer locks where several
+  //    readers can acquire a lock at the same time as long as there
+  //    is no writer waiting for the lock.)  We choose the names 1.)
+  //    to borrow the semantic to give writers higher priority, and,
+  //    2.) to support a common interface over all locking classes in
+  //    ACE.
 public:
   // = Initialization and termination.