On 10/17, Paul E. McKenney wrote: > > On Wed, Oct 17, 2012 at 06:37:02PM +0200, Oleg Nesterov wrote: > > On 10/16, Paul E. McKenney wrote: > > > > > > Suppose that the writer arrives and sees that the value of the counter > > > is zero, > > > > after synchronize_sched(). So there are no readers (but perhaps there > > are brw_end_read's in flight which already decremented read_ctr) > > But the preempt_disable() region only covers read acquisition. So > synchronize_sched() waits only for all the brw_start_read() calls to > reach the preempt_enable()
Yes. > -- it cannot wait for all the resulting > readers to reach the corresponding brw_end_read(). Indeed. > > > and thus never sleeps, and so is also not awakened? > > > > and why do we need wakeup in this case? > > To get the memory barriers required to keep the critical sections > ordered -- to ensure that everyone sees the reader's critical section > as ending before the writer's critical section starts. And now I am starting to think I misunderstood your concern from the very beginning. I thought that you meant that without mb() brw_start_write() can race with brw_end_read() and hang forever. But probably you meant that we need the barriers to ensure that, say, if the reader does brw_start_read(); CONDITION = 1; brw_end_read(); then the writer must see CONDITION != 0 after brw_start_write() ? (or vice-versa) In this case we need the barrier, yes. Obviously brw_start_write() can return right after this_cpu_dec() and before wake_up_all(). 2/2 doesn't need this guarantee but I agree, this doesn't look sane in gerenal... Or I misunderstood you again? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/