*** empty log message ***

4 files changed, 52 insertions, 10 deletions

diff --git a/docs/tutorials/018/combine.shar b/docs/tutorials/018/combine.shar
index 5db5d69e58f..274d7e39816 100644
--- a/docs/tutorials/018/combine.shar
+++ b/docs/tutorials/018/combine.shar
@@ -3,7 +3,7 @@
 # To extract the files from this archive, save it to some FILE, remove
 # everything before the `!/bin/sh' line above, then type `sh FILE'.
 #
-# Made on 1998-11-15 12:38 EST by <jcej@chiroptera.tragus.org>.
+# Made on 1999-02-24 17:02 EST by <jcej@chiroptera.tragus.org>.
 # Source directory was `/var/home/jcej/projects/ACE_wrappers/docs/tutorials/018'.
 #
 # Existing files will *not* be overwritten unless `-c' is specified.
@@ -13,7 +13,7 @@
 # ------ ---------- ------------------------------------------
 #    416 -rw-rw-r-- hdr
 #     64 -rw-rw-r-- bodies
-#   1446 -rw-rw-r-- page01.pre
+#   2603 -rw-rw-r-- page01.pre
 #    430 -rw-rw-r-- page02.pre
 #   1282 -rw-rw-r-- page03.pre
 #    689 -rw-rw-r-- page04.pre
@@ -66,7 +66,7 @@ else
 fi
 rm -f 1231235999 $$.touch
 #
-if mkdir _sh11947; then
+if mkdir _sh30135; then
   $echo 'x -' 'creating lock directory'
 else
   $echo 'failed to create lock directory'
@@ -173,20 +173,41 @@ It gets down to a personal decision based on the application's needs.
 Consider your application, examine its behavior & decide for yourself
 if you want to spread the work evenly or if it's OK to let some
 threads work harder than others.
+<P>
+Kirthika's abstract:
+<UL>
+A token is similar to a mutex-lock, with the difference being that 
+the token is given to the waiting threads in a FIFO order. In the case 
+of the mutex-lock,  any thread (depending on the OS) could acquire 
+the lock when its released. It internally implements a recursive mutex, 
+i.e. the thread that owns the mutex can reqacquire it without deadlocking. 
+The token also has two FIFO lists for writers and readers with writer- 
+acquires having a higher priority than reader-acquires. 
+<P>
+This tutorial throws light on the differences on having a shared resource governed by 
+a lock and a token, both derive from  a Task which simply updates a counter with the 
+number-of-threads value. A barrier is used for ensuring that all threads get a equal 
+opportunity of grabbing the token. The message queue with the message containing the 
+thread count moves among the threads to be obtained and read. 
+<P>
+On obtaining the results, we conclude that on using the Token, the job to be completed 
+can be distributed evenly among available threads. This cant be guaranteed 
+in case of simply using the lock for synchronisation. 
+</ul>
 SHAR_EOF
-  $shar_touch -am 1114142998 'page01.pre' &&
+  $shar_touch -am 0224170199 'page01.pre' &&
   chmod 0664 'page01.pre' ||
   $echo 'restore of' 'page01.pre' 'failed'
   if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
   && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
     md5sum -c << SHAR_EOF >/dev/null 2>&1 \
     || $echo 'page01.pre:' 'MD5 check failed'
-d420fe795c2d1e13cc4a9b4972ba1b47  page01.pre
+89cd84f46240da6d7d4d50e4d303e17a  page01.pre
 SHAR_EOF
   else
     shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'page01.pre'`"
-    test 1446 -eq "$shar_count" ||
-    $echo 'page01.pre:' 'original size' '1446,' 'current size' "$shar_count!"
+    test 2603 -eq "$shar_count" ||
+    $echo 'page01.pre:' 'original size' '2603,' 'current size' "$shar_count!"
   fi
 fi
 # ============= page02.pre ==============
@@ -415,5 +436,5 @@ SHAR_EOF
     $echo 'page07.pre:' 'original size' '478,' 'current size' "$shar_count!"
   fi
 fi
-rm -fr _sh11947
+rm -fr _sh30135
 exit 0
diff --git a/docs/tutorials/018/page01.html b/docs/tutorials/018/page01.html
index 03ce2accfd1..871e8070558 100644
--- a/docs/tutorials/018/page01.html
+++ b/docs/tutorials/018/page01.html
@@ -43,5 +43,26 @@ It gets down to a personal decision based on the application's needs.
 Consider your application, examine its behavior & decide for yourself
 if you want to spread the work evenly or if it's OK to let some
 threads work harder than others.
+<P>
+Kirthika's abstract:
+<UL>
+A token is similar to a mutex-lock, with the difference being that 
+the token is given to the waiting threads in a FIFO order. In the case 
+of the mutex-lock,  any thread (depending on the OS) could acquire 
+the lock when its released. It internally implements a recursive mutex, 
+i.e. the thread that owns the mutex can reqacquire it without deadlocking. 
+The token also has two FIFO lists for writers and readers with writer- 
+acquires having a higher priority than reader-acquires. 
+<P>
+This tutorial throws light on the differences on having a shared resource governed by 
+a lock and a token, both derive from  a Task which simply updates a counter with the 
+number-of-threads value. A barrier is used for ensuring that all threads get a equal 
+opportunity of grabbing the token. The message queue with the message containing the 
+thread count moves among the threads to be obtained and read. 
+<P>
+On obtaining the results, we conclude that on using the Token, the job to be completed 
+can be distributed evenly among available threads. This cant be guaranteed 
+in case of simply using the lock for synchronisation. 
+</ul>
 <P><HR WIDTH="100%">
 <CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page02.html">Continue This Tutorial</A>]</CENTER>
diff --git a/docs/tutorials/018/page02.html b/docs/tutorials/018/page02.html
index 691e8613e5f..b317db06226 100644
--- a/docs/tutorials/018/page02.html
+++ b/docs/tutorials/018/page02.html
@@ -35,7 +35,7 @@ int main(int,char**)
     Token token;
     token.run();
 
-        <font color=red>// And now and ACE_Mutex.</font>
+        <font color=red>// And now the ACE_Mutex.</font>
     Mutex mutex;
     mutex.run();
     
diff --git a/docs/tutorials/018/token.cpp b/docs/tutorials/018/token.cpp
index 995b127014f..771c19988e1 100644
--- a/docs/tutorials/018/token.cpp
+++ b/docs/tutorials/018/token.cpp
@@ -11,7 +11,7 @@ int main(int,char**)
     Token token;
     token.run();
 
-        // And now and ACE_Mutex.
+        // And now the ACE_Mutex.
     Mutex mutex;
     mutex.run();