diff --git a/TODO b/TODO
index 97d9f00719..62d2e562ce 100644
--- a/TODO
+++ b/TODO
@@ -1,4 +1,4 @@
-NuttX TODO List (Last updated October 9, 2016)
+NuttX TODO List (Last updated November 2, 2016)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This file summarizes known NuttX bugs, limitations, inconsistencies with
@@ -217,13 +217,14 @@ o Task/Scheduler (sched/)
   Priority:    Medium-ish
 
   Title:       ISSUES WITH PRIORITY INHERITANCE WHEN SEMAPHORE USED AS IPC
-  Description: The semaphores have multiple uses. The typical usage is where
+  Description: Semaphores have multiple uses.  The typical usage is where
                the semaphore is used as lock on one or more resources.  In
                this typical case, priority inheritance works perfectly:  The
                holder of a semaphore count must be remembered so that its
                priority can be boosted if a higher priority task requires a
-               count from the semaphore.  It remains the holder until is
-               calls sem_post() to release the count on the semaphore.
+               count from the semaphore.  It remains the holder until the
+               same task calls sem_post() to release the count on the
+               semaphore.
 
                But a different usage model for semaphores is for signalling
                events.  In this case, the semaphore count is initialized to
@@ -237,11 +238,14 @@ o Task/Scheduler (sched/)
                TASK B (or perhaps an interrupt handler) signals task A of
                the occurence of the events by posting the semaphore:
 
+                 ---------------------- ---------------
                  TASK A                 TASK B
+                 ---------------------- ---------------
                  sem_init(sem, 0, 0);
                  sem_wait(sem);
                                         sem_post(sem);
                  Awakens as holder
+                 ---------------------- ---------------
 
                These two usage models are really very different and priority
                inheritance simply does not apply when the semaphore is used for
@@ -249,12 +253,13 @@ o Task/Scheduler (sched/)
                priority inheritance can interfere with the operation of the
                semaphore.  The problem is that when TASK A is awakened it is
                a holder of the semaphore.  Normally, a task is removed from
-               the holder list when it finally release the 
+               the holder list when it finally releases the semaphore via
+               sem_post().
               
                However, TASK A never calls sem_post(sem) so it becomes
                *permanently* a holder of the semaphore and may have its
-               priority boosted when any other task tries to acquire the
-               semaphore.
+               priority boosted at any time when any other task tries to
+               acquire the semaphore.
 
                The fix is to call sem_setprotocol(SEM_PRIO_NONE) immediately
                after the sem_init() call so that there will be no priority