Messages in this thread | | | Date | Wed, 10 Nov 1999 17:25:05 +0100 (CET) | From | Andrea Arcangeli <> | Subject | set_current_state() vs __set_current_state() |
| |
@@ -95,7 +95,7 @@ our interrupt handler called. */ if (count && no_irq) { parport_release (dev); - current->state = TASK_INTERRUPTIBLE; + set_current_state (TASK_INTERRUPTIBLE); schedule_timeout (wait); parport_claim_or_block (dev); }
This is definitely _safe_ but slower.
NOTE: set_current_state() is _always_ safe. __set_current_state() may be race prone if not used carefully in the wait_event interface.
In the sepecific above case you can safely use the faster __set_current_state() because you know the schedule will run on the same CPU that you used to set the state as TASK_INTERRUPTIBLE. You are changing the `state' field only for yourself. So you don't care what other CPUs will see as you have not to deal with other CPUs in such case.
The signal handling can't race as schedule is aware of signals and schedule will check if there's a signal pending after flushing the TASK_INTERRUPTIBLE state to the other CPUs and the signal path will first set the signal_pending bit, then it flush the bit to RAM and it will go to check the state of the signalled process. So the right ordering is just enforced by the scheduler and the signal code.
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/
| |