Add a comment explaining td_critnest's initial state and its life from that

point on, as it happens relatively indirectly, and in a codepath the casual
reader may not be acquainted with or find obvious.

Glanced at by:	jhb

1 files changed, 13 insertions, 0 deletions

diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c
index 242fba5..7b1d45e 100644
--- a/sys/kern/kern_thread.c
+++ b/sys/kern/kern_thread.c
@@ -124,6 +124,19 @@ thread_ctor(void *mem, int size, void *arg)
 	td->td_tid = 0;
 	td->td_state = TDS_INACTIVE;
 	td->td_oncpu	= NOCPU;
+
+	/*
+	 * Note that td_critnest begins life as 1 because the thread is not
+	 * running and is thereby implicitly waiting to be on the receiving
+	 * end of a context switch.  A context switch must occur inside a
+	 * critical section, and in fact, includes hand-off of the sched_lock.
+	 * After a context switch to a newly created thread, it will release
+	 * sched_lock for the first time, and its td_critnest will hit 0 for
+	 * the first time.  This happens on the far end of a context switch,
+	 * and when it context switches away from itself, it will in fact go
+	 * back into a critical section, and hand off the sched lock to the
+	 * next thread.
+	 */
 	td->td_critnest = 1;
 }