On Thu, Oct 18, 2012 at 06:24:09PM +0200, Oleg Nesterov wrote: > 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)
Yes, this is exactly my concern. > 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 name it something not containing "lock". And clearly document the behavior and how it is to be used. ;-) Otherwise, someone will get confused and introduce bugs. > Or I misunderstood you again? No, this was indeed my concern. Thanx, Paul -- 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/