Re: [Kernel-janitors] Re: set_current_state

[Felipe W Damasio <felipewd@terra.com.br>]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Anupam Kapoor wrote:
> can you please elaborate what you mean here, i don't understand the
> connotations sorry !

	There's the classic example that rml used when he wrote a few 
explanation notes of when set_current_state should be used.

	If we're setting the current task to TASK_* (other than RUNNING) and 
after that, manipulating some variable:

	current->state = TASK_INTERRUPTIBLE;
	if (doritos)
	{
		...
	}

	And on some of other code path we're checking to see if we're in 
TASK_INTERRUPTIBLE to also use the same variable:

	if (current->state == TASK_INTERRUPTIBLE)
	{
		do-something-to-doritos;
	}

	Then, in this case, we need a memory barrier the guarantee that the 
doritos variable will have the state set correctly _before_ manipulating it.

	But again, state setting that are still open coded are not that simple 
to see if we need set_current_state.

	Most places it's not the end of the world to have an useless memory 
barrier, but if we could things right and save an useless 
instruction..it'd be better.

	In short: If in doubt, always use set_current_state. :-)

	Cheers,

Felipe
-- 
It's most certainly GNU/Linux, not Linux. Read more at
http://www.gnu.org/gnu/why-gnu-linux.html

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors