x86和arm对于锁实现的差异

最近把一个分布式存储的application从x86移植到aarch64上，经过一大坨编译问题的改动，及一些汇编指令的修改，已经能够正常跑job了（这里已经解决syscall number不一致， page size64k等问题）。但是在测试terasort的时候，跑100G任务没问题，跑1T的任务会出现进程coredump的问题， gdb的发现a=b->c 类似这句话出错，出错的原因是b的不对，要么是0要么是一个非常大的值。

分析代码发现，这个b是从一个list里面取出来的。然后list add是在另外一个线程中操作的，所以直觉是锁不对。然后查看application代码，发现自己实现了一个所谓spinlock的东西，就是类似cmpxchg的东西，循环判断是否执行成功。这里我们已经把cmpxchg替换成gcc builtin的函数，通过汇编看到是ldaxr xx, stlxr。ldaxr 就是Load-acquire exclusive register，stlxr是store-release， 查看arm手册，理解这个是可以对应到x86的spin lock实现

开始怀疑是因为x86里面的store buffer刷新机制跟arm不一样，因为x86里面memory barrier跟 store buffer，集成在一起，mfence类指令，既可以保证顺序也可以保证store buffer，但是arm里面是有两个指令，dmb, dsb， 前者只保证memory barrier, 后者保证pipeline之类的被刷干净。但是仔细一想，如果是因为store buffer的问题，顶多是出现锁拿不到，多等一会儿，不至于出错。

后面再仔细看了下spinlock的实现，关键在于spin_unlock里面。他的实现是asm{":::memory"}, lock=0之类的写法。这个在x86的架构上是没有问题的，因为x86保证写不会乱序，所以lock=0，不会再unlock之前调用。但是在arm里面，写是可以乱序，所以lock=0，可能在unlock之间的保护区代码中间执行。经过测试发现，把memory修改为dmb ish:::memory之后，不在出现coredump