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

你可能感兴趣的:(arch)