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

[Eric Haszlakiewicz <erh%nimenees.com@localhost>]

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:
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?

eric