Re: 4.x -> 5.x locking?

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

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.

Joerg