Messages in this thread | | | Date | Wed, 26 Nov 2008 15:39:00 +0900 | From | Tejun Heo <> | Subject | Re: [PATCH] poll: allow f_op->poll to sleep, take#5 |
| |
Hello,
Davide Libenzi wrote: > Look, pollwake() does: > > w1) WR triggered (1) > w2) WMB > w3) WR task->state (RUNNING) > > While poll_schedule_timeout() does: > > s1) WR task->state (TASK_INTERRUPTIBLE) > s2) MB > s3) RD triggered > s4) IF0 => RD task->state (if !RUNNING -> sleep) s5) after waking up, WR triggered to zero
> The only risk is that w3 preceed s1, so that we go to sleep even though a > wakeup has been issued. But if w3 is visible, w1 is visible too, that > means that 'triggered' is visible in s3 (there's a MB in s2). So we skip > the schedule_hrtimeout_range(). So IMO you need no barriers on 'triggered'. > If you feel you need barriers, do you mind explaning a sequence of events > that makes a barrier-free version break?
s5 from the previous iteration could happen after w1 during the next iteration and the test in s4 of the next iteration will miss the event, so the event could get lost on the iterations which is not the first one, no?
Thanks.
-- tejun
| |