Re: pserialize(9) vs. TAILQ

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Sun, 23 Nov 2014, Dennis Ferguson wrote:

> On 23 Nov, 2014, at 01:01 , Martin Husemann <martin%duskware.de@localhost> wrote:
> 
> > On Sat, Nov 22, 2014 at 01:24:42PM +0800, Dennis Ferguson wrote:
> >> I'll guess one problem is in sparc/mutex.h, here:
> >> 
> >>    #define MUTEX_RECEIVE(mtx)              /* nothing */
> >>    #define MUTEX_GIVE(mtx)                 /* nothing */
> >> 
> >> This works with TSO, but with RMO they need to somehow generate
> >> hardware memory barriers.  See arm/mutex.h for an example with
> >> them filled in.
> > 
> > Or src/sys/arch/sparc64/include/mutex.h - IIRC sparc v8 and earlier do not
> > have RMO.
> 
> Ah, got it.  I'd now guess that in
> 
>    src/common/lib/libc/arch/sparc64/atomic/membar_ops.S
> 
> this comment
> 
>     /* These assume Total Store Order (TSO) */
> 
> suggests the problem.

Yes, the existing code assumes TSO.  A while back I was looking in to fixing that.  

I enhanced membar_ops with proper memory barriers and then was looking at 
the mutex code.  Unfortunately, I didn't get very far.  It seemed at the 
time that the mutex code has two hooks for memory barriers after the 
atomic operations, however it's missing memory barrier hooks to ensure 
consistency before accessing the lock.

Eduardo