diff --git a/doc/faq.html b/doc/faq.html
new file mode 100644
index 00000000..2ec4517d
--- /dev/null
+++ b/doc/faq.html
@@ -0,0 +1,50 @@
+<html>
+
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<meta name="keywords" content="threads, BTL, thread library, C++">
+<title>Boost.Threads, FAQ</title>
+</head>
+
+<body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
+
+<table border="0" cellpadding="7" cellspacing="0" width="100%">
+    <tr>
+        <td valign="top" width="300">
+			<h3><img src="../../../c++boost.gif" alt="C++ Boost" width="277" height="86"></h3>
+        </td>
+        <td valign="top">
+			<h1 align="center">Boost.Threads</h1>
+			<h2 align="center">Frequently Asked Questions</h2>
+        </td>
+    </tr>
+</table>
+
+<hr>
+
+<h2>Are lock objects thread safe?</h2>
+
+<p><b>No!</b>  Lock objects are not meant to be shared between threads.  They are meant to
+be short lived objects created on automatic storage within a code block.  Any other usage
+is just likely to lead to errors and won't really be of actual benefit any way.  Share
+mutexes, not locks.  For more information on this see the documentation on the
+<a href="rationale.html#lock_objects">rationale</a> behind the design for lock objects.</p>
+
+<h2>Why was Boost.Threads modelled after the (platform specific library name)
+library?</h2>
+
+<p>It wasn't.  As the developer I tried very hard to not let my own biases show in the
+development of this library.  Each library has its own strengths and weaknesses and I wanted
+to avoid the mistakes made by others (though I'm sure I made plenty of my own).  For instance,
+inclusion of a max value for semaphores seemed like a smart decision despite the lack of support
+for this concept in POSIX.  On the other hand, lack of a condition variable concept in the
+Windows API was a big mistake since it's the only way to model a monitor pattern.  If you think
+you see a bias for any platform/library, you're probably wrong.</p>
+
+<hr>
+
+<p><i>Copyright <a href="mailto:williamkempf@hotmail.com">William E. Kempf</a>
+2001 all rights reserved.</i></p>
+
+</body>
+</html>
diff --git a/doc/index.html b/doc/index.html
index e133fa64..48416810 100644
--- a/doc/index.html
+++ b/doc/index.html
@@ -48,6 +48,7 @@
 	<li><a href="thread_formal_definition.html">Formal definition of
       &quot;Thread&quot;</a></li>
     <li><a href="rationale.html">Rationale for design decisions</a></li>
+    <li><a href="faq.html">Frequently Asked Questions</a></li>
 </ul>
 
 <hr>
diff --git a/doc/rationale.html b/doc/rationale.html
index 29951e29..3b3a6b42 100644
--- a/doc/rationale.html
+++ b/doc/rationale.html
@@ -28,7 +28,7 @@ design as well as prevent future rehashing of discussions and thought processes
 already occured.  It can also give users a lot of insight into the design process required
 for this library.</p>
 
-<h2>Rationale for the Creation of Boost.Threads</h2>
+<h2><a name="library">Rationale for the Creation of Boost.Threads</a></h2>
 
 <p>Processes often have a degree of "potential parallelism" and it can often be more intuitive
 to design systems with this in mind.  Further, these parallel processes can result in more responsive
@@ -53,7 +53,7 @@ for writing multi-threaded programs on numerous platforms.  There's a hope that
 be the basis for a more detailed proposal for the C++ standards committee to consider for inclusion
 in the next C++ standard.</p>
 
-<h2>Rationale for the Low Level Primitives Supported in Boost.Threads</h2>
+<h2><a name="primitives">Rationale for the Low Level Primitives Supported in Boost.Threads</a></h2>
 
 <p>The Boost.Threads library supplies a set of low level primitives for writing multi-threaded
 programs, such as semaphores, mutexes and condition variables.  In fact, the first release of
@@ -75,7 +75,7 @@ useful in and of themselves, even if it's hard to prove that their usage is corr
 many users will be familiar with these lower level concepts but be unfamiliar with any of the 
 higher level concepts there's also an argument for accessibility.</p>
 
-<h2>Rationale for the Lock Design</h2>
+<h2><a name="lock_objects">Rationale for the Lock Design</a></h2>
 
 <p>Programmers who are used to multi-threaded programming issues will quickly note that the
 Boost.Thread's design for mutex lock concepts is not thread safe (this is clearly documented
@@ -105,7 +105,7 @@ safe.  Instead, sharing a lock object between threads results in undefined behav
 only proper usage of lock objects is within block scope this isn't a problem, and so long
 as the lock object is properly used there's no danger of any multi-threading issues.</p>
 
-<h2>Rationale for Non-copyable Thread Type</h2>
+<h2><a name="thread">Rationale for Non-copyable Thread Type</a></h2>
 
 <p>Programmers who are used to C libraries for multi-threaded programming are likely to
 wonder why Boost.Threads uses a non-copyable design for boost::thread.  After all, the C
