diff --git a/ChangeLog b/ChangeLog
index 181082fc7f..da2341872c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -98,6 +98,9 @@
 	  task_delete() can cause pending tasks to be merged and a
 	  context switch to occur.
 	* Added mq_timedreceive() and mq_timedsend()
+	* signal mask is now inherited by both child tasks and threads.
+	* Improved sharebility of stdout among pthreads (only).  Nothing
+	  was broken, but by moving the mutual exclusion logic to a
+	  higher level, the printf output is more readable.
 	* Started m68322
 
-
diff --git a/Documentation/NuttX.html b/Documentation/NuttX.html
index fcdb9b1d12..80c51178aa 100644
--- a/Documentation/NuttX.html
+++ b/Documentation/NuttX.html
@@ -8,7 +8,7 @@
   <tr align="center" bgcolor="#e4e4e4">
     <td>
       <h1><big><font color="#3c34ec"><i>NuttX RTOS</i></font></big></h1>
-      <p>Last Updated: March 21, 2007</p>
+      <p>Last Updated: March 28, 2007</p>
     </td>
   </tr>
 </table>
@@ -459,6 +459,10 @@ Other memory:
 	  task_delete() can cause pending tasks to be merged and a
 	  context switch to occur.
 	* Added mq_timedreceive() and mq_timedsend()
+	* signal mask is now inherited by both child tasks and threads.
+	* Improved sharebility of stdout among pthreads (only).  Nothing
+	  was broken, but by moving the mutual exclusion logic to a
+	  higher level, the printf output is more readable.
 	* Started m68322
 </pre></ul>
 
diff --git a/TODO b/TODO
index 6e9bcea8e9..1b229bbb75 100644
--- a/TODO
+++ b/TODO
@@ -1,9 +1,7 @@
 NuttX TODO List
 ^^^^^^^^^^^^^^^
 
-Task/Scheduler
-^^^^^^^^^^^^^^
-
+o Task/Scheduler
 - When a tasks exits, shouldn't all of its child pthreads also be terminated?
 - Should task_delete() cause atexit() function to be called?
 - Implement sys/mman.h and functions
@@ -27,16 +25,6 @@ o pthreads
 - pthread_cancel():  Should implemenent cancellation points and pthread_testcancel()
 
 o Libraries
-- There seems to be some kind of failure in the mutual exclusion logic on
-  buffered, "standard," IO.
-  - If two threads try fflush-ing at the same time, there is corruption
-    of the output.
-  - Yhere is a failure in the examples/ostest POSIX timer
-    test when CONFIG_DEBUG is enabled.  This is almost certainly yet
-    another case where printf (or its kin) are being called from a 
-    sensitive area in the OS.
-  - I am now seeing the same thing with the dm320 barrier test.
-    Apparently printf has some thread safety issues.
 
 o File system
 - Add some concept like mount points to handle mounted "real" filesystems.
@@ -63,7 +51,7 @@ o C5471
 o DM320
 
 o pjrc-8052 / MCS51
-* Current status:
+- Current status:
   - Basic OS task management seems OK
   - Fails when interrupts enabled.  The stack pointer is around 0x6e
     before the failure occurs.  It looks like some issue when the
diff --git a/lib/lib_vfprintf.c b/lib/lib_vfprintf.c
index 7d1b666a40..fe8b1a744a 100644
--- a/lib/lib_vfprintf.c
+++ b/lib/lib_vfprintf.c
@@ -87,7 +87,15 @@ int vfprintf(FILE *stream, const char *fmt, va_list ap)
        */
 
       lib_stdstream(&stdstream, stream);
+
+      /* Hold the stream semaphore throughout the lib_vsprintf
+       * call so that this thread can get its entire message out
+       * before being pre-empted by the next thread.
+       */
+
+      lib_take_semaphore(stream);
       n = lib_vsprintf(&stdstream.public, fmt, ap);
+      lib_give_semaphore(stream);
     }
   return n;
 }