Messages in this thread | | | Date | Sat, 4 Sep 1999 17:01:53 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: set_current_state |
| |
On Wed, 1 Sep 1999, Theodore Y. Ts'o 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.
>wonder why you only changed that one line, but not all of the other >lines in the driver which set current->state. Doing a quick grep over
I checked all drivers in the kernel and I changed _only_ the places which needs the memory barrier to reduce the size of the patch.
All places that are using `current->state = ...' can be converted to __set_current_state(...) of course, but that's only a coding issue and the assembler generated will be the same. I am not worried by such conversion since they are the same thing.
>Are there any circumstances where we should keep the old usage? Or
The old usage or __set_current_state() are the same thing. All places that currently are not using set_current_state() _should_ continue with the old usage or be converted to __set_current_state() (note the __).
If unsure set_current_state() is _always_ safe, but it will be slower than __set_current_state. So if there's some kind of implicit memory barrier between setting the task state and the read of the codition to break the wait-event loop, then you can safely use __set_current_state().
Andrea
- 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/
| |