Simplified priority inheritance explanation (#88)

Add explanation of mutex priority inheritance
behavior along with important differences a
user should be aware of.

Author: kstribrnAmzn

ch08.md

@@ -692,6 +692,9 @@ undesirable behavior would be exaggerated further if a medium priority
 task started to execute while the high priority task was waiting for the
 semaphore—the result would be a high priority task waiting for a low
 priority task—without the low priority task even being able to execute.
+This is most often referred to as _unbounded priority inversion_ because
+the medium priority task could block the low and high priority tasks
+indefinitely.
 This worst case scenario is shown in Figure 8.4.
 
 
@@ -737,6 +740,22 @@ As just seen, priority inheritance functionality effects the priority of
 tasks that are using the mutex. For that reason, mutexes must not be
 used from interrupt service routines.
 
+FreeRTOS implements a basic priority inheritance mechanism which was
+designed with optimizing both space and execution cycles in mind. A full
+priority inheritance mechanism requires significantly more data and
+processor cycles to determine inherited priority at any moment,
+especially when a task holds more than one mutex at a time.
+
+Specific behaviors of the priority inheritance mechanism to keep in mind:
+* A task can have its inherited priority raised further if it
+  takes a mutex without first releasing mutexes it already holds.
+* A task remains at its highest inherited priority until
+  it has released all the mutexes it holds. This is regardless of
+  the order the mutexes are released.
+* A task will remain at the highest inherited priority if multiple
+  mutexes are held regardless of tasks waiting on any of the held
+  mutexes completing their wait (timing out).
+
 
 ### 8.3.4 Deadlock (or Deadly Embrace)