AMRv8架构中对于A64,提供了如下的一些exclusive指令,用来支持exclusive操作。
那为什么,arm在加入exclusive指令呢?加入这个,主要是为了解决多核情况下,锁的竞争问题。
在软件层面,对于共享资源的访问,会设定一个锁,只有能拿到这个锁的程序,才能够访问共享资源,而没有拿到锁的程序,就不能访问该共享资源。
拿到锁的程序,在访问完毕后,要释放锁,这样,其他的程序,才可以竞争该锁,从而访问共享资源。
其伪代码如下:
//获取锁get_lock: ldr w1, [x0] cmp w1, #1 b.ne get_lock mov w1, #1 str w1, [x0] //开始访问共享资源 ... //结束访问共享资源unlock: mov w1, #0 str w1, [x0]读取锁,如果为非0,表示当前锁被其他程序占有,因此获取锁失败,就一直要等别人释放锁。如果锁的值为0,表示锁没有被其他程序占有,那么将锁置为1,然后访问共享资源。访问完毕后,将锁置为0,释放锁。
这个获取锁的程序,在单核的时候,可以运行得比较良好,因为在同一个时刻,只能有一个程序在执行,不存在竞争的问题。
在使用操作系统后,这个程序也可能会出现潜在的问题,因为操作系统会调度应用程序。假设应用程序A在读取到锁状态后,值为0,表示当前锁没有被其他程序占有,正当自己要将锁锁上的时候,操作系统进行了调度,应用程序B执行。程序B也读取锁状态,发现值为0,表示当前锁没有被其他程序占有,然后将锁给锁上,访问共享资源。此时,操作系统又进行了调度,应用程序A执行,将锁给锁上,然后访问共享资源。那此时,就出现了2个应用程序,同时访问共享资源,锁的作用,被屏蔽了。
其执行过程,如下表所示:
程序A | 当前执行 | 程序B |
ldr w1,[x0] 获取锁状态为0 | 程序A | |
程序B | ldr w1,[x0] 获取锁状态为0 | |
程序B | str w1, [x0] 上锁,锁状态为1 | |
程序B | 访问共享资源 | |
b.ne get_lock 此时锁状态为1,但是A不知道 | 程序A | |
str w1, [x0] 上锁 | 程序A | |
访问共享资源 | 程序A |
为了解决这个问题,可以在获取锁的时候,屏蔽中断,那这个时候,操作系统就不能调度,也就避免上面出现的问题。伪代码如下所示:
get_lock: //关中断 bl mask_int ldr w1, [x0] cmp w1, #1 b.ne get_lock mov w1, #1 str w1, [x0] //开中断 bl open_int //访问共享资源 ... unlock: mov w1, #0 str w1, [x0]这样,可以避免上述的问题,但是只要获取锁,就要关中断,开中断,这影响了系统响应中断的实时性。
在单核的时候,还可以通过关闭中断,来阻止操作系统调度。但是在多核的情况下,各个cpu是并行执行的,因此这个时候,就会出现,上面描述的2个程序,同时获取到锁的状态,而这个时候,通过禁止中断,是没有效果的。
为了解决多核情况下的锁竞争问题,arm引入了exclusive操作,并添加了相应的指令。
exclusive的操作的核心,就是会将锁,用一个状态机进行维护,该状态机有2种状态,open状态和exclusive状态。要想成功的对锁进行上锁,状态必须要从exclusive状态切换到open状态,其他状态,都是失败的。
为了支持exclusive操作,在A64,新增了LDXR和STXR指令。
在A32和T32下,也加入LDREX和STREX指令来支持。
LDXR指令,将状态从open状态切换到exclusive状态,STXR指令,将状态从exclusive状态切换到open状态,这个就表示store exclusive操作成功。
STXR指令和普通的STR指令,不同的是,该指令有返回值,表示store exclusive是否成功。如果成功,ws为0,不成功,ws为1。
当有了exclusive操作指令后,之前的获取锁的程序,就变为以下:
//获取锁get_lock: ldxr w1, [x0] cmp w1, #1 b.ne get_lock //尝试上锁 mov w1, #1 stxr w2, w1, [x0] cbnz w2, get_lock //访问资源 ... unlock: mov w1, #0 str w1, [x0]通过stxr指令,尝试更改锁的状态,如果更改成功,那么w2为0,此时就表示自己获取到锁,然后就可以访问共享资源。如果更改失败,那么w2为1,表示此时其他程序获取到该锁,就不能访问共享资源,回到获取锁。
联系客服