April 8, 2008
A quick note regarding Linux "tasks."
In an exchange regarding a race between timer ticks (and updates of task->utime versus task->signal->(somepointer)->utime), Roland McGrath told me that
current->exit_state can go from zero to nonzero only by current running code in the do_exit path. current does not progress on that path while current is inside one update_process_times call.
The key bit of knowledge that I was lacking and that this (when placed with other information I had gained in the extended email exchange) was that a "task" is really a Linux scheduling unit. From the scheduler's perspective, "task" is the same as "thread." The only thing that makes a set of threads into a multithreaded process is that they share a signal_struct (and their memory map, of course, and a several other things that, as Roland says, are implicitly required to be shared when signal_struct is shared). So a "task" can only be executed on a single cpu at any time, it can't be executed on more than one cpu at a time. Therefore if a "task" is executing and is interrupted, the value of "current" at the interrupt will be that task, which is entirely suspended for the duration of the interrupt.