diff options
author | Andrew Morton <akpm@osdl.org> | 2005-09-13 01:25:14 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2005-09-13 08:22:29 -0700 |
commit | 498d0c5711094b0e1fd93f5355d270ccebdec706 (patch) | |
tree | e155f09b6f5b752171638028e574947e275cc3d9 /drivers/char | |
parent | 921717a2a1cde78c9b2aa971c16510d63efe7320 (diff) | |
download | blackbird-op-linux-498d0c5711094b0e1fd93f5355d270ccebdec706.tar.gz blackbird-op-linux-498d0c5711094b0e1fd93f5355d270ccebdec706.zip |
[PATCH] set_current_state() commentary
Explain the mysteries of set_current_state().
Quoth Linus:
The scheduler itself never needs the memory barrier at all.
The barrier is needed only if the user itself ends up testing some other
thing afterwards, ie if you have
set_process_state(TASK_INTERRUPTIBLE);
if (still_need_to_sleep())
schedule();
then the "still_need_to_sleep()" thing may test flags and wakeup events,
and then you _may_ want to (and often do) make sure that the write of
TASK_INTERRUPTIBLE is serialized wrt the reads of any wakeup data (since
the wakeup may have happened on another CPU).
So the comment is somewhat wrong. We don't really _care_ whether the state
propagates out to other CPU's since all of our actions are purely local,
and there is nothing we do that is conditional on any other CPU: we're
going to sleep unconditionally, and the scheduler only cares about _our_
state, not about somebody elses state.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'drivers/char')
0 files changed, 0 insertions, 0 deletions