Linux-kernel mailing list archive 1999-36,: Re: set_current_state

# Re: set_current_state

list.kernel@iahastie.clara.net
Sun, 5 Sep 1999 19:15:19 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: list.kernel@iahastie.clara.net: "iput: Aieee, semaphore in use inode 00:00/XXX, count=2"
- Previous message: list.kernel@iahastie.clara.net: "Re: SMP linux help"

Andrea Arcangeli wrote:
> >Looking at the sched.h header file, it's pretty clear that this is there
> >to protect against race conditions on SMP kernels. Which makes me
>
> Exactly, I noticed the SMP race some week ago (see the thread SMP races
> all over the place). You can find all the details on linux-kernel.

I've been wondering why this is safe on UP.

What's to stop the compiler reordering the write to current->state
after the test for the condition?

Sure, state is declared volatile, but the condition usually isn't and
AFAIK the ordering of volatile operations is only defined with respect
to each other.

Scenario:

current->state = TASK_INTERRUPTIBLE;
if (condition)

Rewritten by compiler as:

tmp = condition;
/* Interrupt occurs here. */
current->state = TASK_INTERRUPTIBLE;
if (tmp)

Just a thought. Obviously it never happens so I must be missing
something :-)

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: list.kernel@iahastie.clara.net: "iput: Aieee, semaphore in use inode 00:00/XXX, count=2"
- Previous message: list.kernel@iahastie.clara.net: "Re: SMP linux help"