Messages in this thread | | | Date | Thu, 18 Oct 2012 18:24:09 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 1/2] brw_mutex: big read-write mutex |
| |
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.
| |