[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: 4.x -> 5.x locking?
On Wed, Nov 09, 2011 at 09:52:13AM -0600, Eric Haszlakiewicz wrote:
> On Wed, Nov 09, 2011 at 04:03:50PM +0100, Joerg Sonnenberger wrote:
> > On Wed, Nov 09, 2011 at 09:37:47AM -0500, Mouse wrote:
> > > >> membar_sync();
> > > >> mutex_exit(mtx);
> > > > mutex_enter and mutex_exit are implicit memory barriers (reads and
> > > > writes respectively are not allowed to be reordered).
> > >
> > > Oh! Thank you. Has that made it into mutex(9) in -current? If not, I
> > > offer my opinion that it should.
> > >
> > > Does mutex_exit also implicitly push writes to main RAM, or whatever
> > > else is necessary to make them visible to other CPUs? (A reordering
> > > barrier does not necessarily imply a global visibility barrier.)
> > I don't think it guarantees it by itself. That is, if you want to access
> > the data on a different CPU, you either need to take the mutex (and the
> > read barrier in mutex_enter) or issue an explicit barrier.
> I'm a bit unclear still. Do you mean that in this sequence:
0: x = 0
> 1: CPU A: mutex_enter(mtx)
> 2: CPU A: x = 1
> 3: CPU A: mutex_exit(mtx)
> 4: CPU B: mutex_enter(mtx)
> 5: CPU B: dostuff(x);
> The value changed in step #2 is only guaranteed to be available on CPU B
> after Step #4 runs? i.e. the mutex_enter call does "something" to ensure that
> all changes from all other CPUs are visible?
Yes. What can happen without step 4 is that step 5 still sees the 0.
Main Index |
Thread Index |