From 0c6f5592b956c6a5c11c3b422e523d961f8afa45 Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Fri, 7 Jul 2006 01:52:28 +0000 Subject: [PATCH] New FAQ. --- doc/threads.texi | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/doc/threads.texi b/doc/threads.texi index 706f76b..7964879 100644 --- a/doc/threads.texi +++ b/doc/threads.texi @@ -640,6 +640,45 @@ that happens to follow @func{fail} in memory, which in this case happens to be @func{pass}. @xref{Backtraces}, for more information. + +@item How do interrupts get re-enabled in the new thread following @func{schedule}? + +Every path into @func{schedule} disables interrupts. They eventually +get re-enabled by the next thread to be scheduled. Consider the +possibilities: the new thread is running in @func{switch_thread} (but +see below), which is called by @func{schedule}, which is called by one +of a few possible functions: + +@itemize @bullet +@item +@func{thread_exit}, but we'll never switch back into such a thread, so +it's uninteresting. + +@item +@func{thread_yield}, which immediately restores the interrupt level upon +return from @func{schedule}. + +@item +@func{thread_block}, which is called from multiple places: + +@itemize @minus +@item +@func{sema_down}, which restores the interrupt level before returning. + +@item +@func{idle}, which enables interrupts with an explicit assembly STI +instruction. + +@item +@func{wait} in @file{devices/intq.c}, whose callers are responsible for +re-enabling interrupts. +@end itemize +@end itemize + +There is a special case when a newly created thread runs for the first +time. Such a thread calls @func{intr_enable} as the first action in +@func{kernel_thread}, which is at the bottom of the call stack for every +kernel thread but the first. @end table @menu -- 2.30.2