[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 <[e-mail]>
Signed-off-by: Linus Torvalds <[e-mail]>

include/linux/sched.h

···
 #define set_task_state(tsk, state_value)		\
 	set_mb((tsk)->state, (state_value))
 
+/*
+ * set_current_state() includes a barrier so that the write of current->state
+ * is correctly serialised wrt the caller's subsequent test of whether to
+ * actually sleep:
+ *
+ *	set_current_state(TASK_UNINTERRUPTIBLE);
+ *	if (do_i_need_to_sleep())
+ *		schedule();
+ *
+ * If the caller does not need such serialisation then use __set_current_state()
+ */
 #define __set_current_state(state_value)			\
 	do { current->state = (state_value); } while (0)
 #define set_current_state(state_value)		\