[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 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?
Main Index |
Thread Index |