Author | baron
Source | Arm Selected
Note: Although this article uses the spinlock function as an example, it does not provide an in-depth analysis of the spinlock function. The focus of this article is on the exclusive mechanism.
Basic Knowledge
- Each core has an Internal Exclusive Monitor, which has open and exclusive states, managing: Load-Exclusive accesses, Store-Exclusive accesses, and Clear-Exclusive (CLREX) instructions.
- Load-Exclusive instructions and Store-Exclusive instructions areLDX, LDAX, STX, STLX
- These instructions can be used to construct semaphores and spinlocks to ensure synchronization operations between different threads on the same core. The same coherent memory locations can also be used between different cores to ensure synchronization.
- The Load-Exclusive instruction marks a block for exclusive access to memory, and CTR_EL0 defines the size of this block.
LDXR Wt, [base{,#0}](1) Read a number from the
<span>base</span>address and store it in the Wt register;
(2) Change the Monitor’s state to exclusive.STXR Ws, Wt, [base{,#0}](1) Write the data in Wt to the<span>base</span>address; if successful, Ws returns 0; otherwise, it returns 1;
(2) Change the Monitor from exclusive state to open; if the switch is successful, it indicates the write was successful, and Ws returns 0; if the switch fails, the data will not be written to memory, and Ws returns 1.
Analysis: To use the exclusive instruction to store a number, it is necessary to first use the ldx/ldax instruction to set the Monitor to exclusive state, at which point it can proceed to the store operation. After the store is completed, the Monitor will switch from exclusive back to open state. In simpler terms: if I want to write a number to an address in exclusive mode, I must first seize the monitor, then I can write data to the relevant address.
Example 1: Accessing Different Locks on the Same Core
Here is an implementation of a spinlock. When two threads on the same core execute this segment of code:
FUNC cpu_spin_lock , :
mov w2, #SPINLOCK_LOCK
sevl
l1: wfe
l2: ldaxr w1, [x0]
cbnz w1, l1
stxr w1, w2, [x0]
cbnz w1, l2
ret
END_FUNC __cpu_spin_lock
- 1. Thread1 first calls cpu_spin_lock[&lock1] and reaches ldaxr; at this point, the Internal Exclusive Monitor is marked as exclusive state. In other words, the core is already in Exclusive Access state, preparing for a write operation.
- 2. Then thread2 also calls cpu_spin_lock[&lock2] and reaches ldaxr; at this point, the Internal Exclusive Monitor is already in exclusive state, no need to reset. In other words, the core remains in Exclusive Access state, preparing for a write operation.
- 3. Next, thread1 calls the stxr operation, and it succeeds, successfully writing w2 to the [X0] address, with w1 returning 0 indicating success. The Internal Exclusive Monitor will switch from exclusive to open state.
- 4. Then thread2 calls the stxr operation; since the Internal Exclusive Monitor is now in open state, this write operation will fail. Thus, w2 will not be written to [X0], and w1 returns 1, indicating to the program: “Hey, this step did not pass!”
- 5. Following the program’s logic, after thread2 fails the stxr operation, w1 returns 1, and the program jumps back to
<span>l2</span>to try again…
Example 2: Accessing Different Locks on Different Cores
Using the same example, what happens if different CPUs acquire the same lock?
- 1. Thread1 first calls cpu_spin_lock[&lock1] and reaches ldaxr; at this point, core1‘s Internal Exclusive Monitor is marked as exclusive state. In other words, core1 is in Exclusive Access state, preparing for a write operation.
- 2. Then thread2 also calls cpu_spin_lock[&lock2] and reaches ldaxr; at this point, core2‘s Internal Exclusive Monitor is marked as exclusive state, meaning core is still in Exclusive Access state, preparing for a write operation.
- 3. Next, thread1 calls the stxr operation, and it succeeds, successfully writing w2 to the [X0] address, with w1 returning 0 indicating success. The Internal Exclusive Monitor will switch from exclusive to open state.
- 4. Then thread2 also calls the stxr operation; since core2‘s Internal Exclusive Monitor is still in exclusive state, this write operation will succeed.
Example 3: Accessing the Same Lock on Different Cores
Using the same example, what happens if different CPUs acquire the same lock?
- 1. Thread1 first calls cpu_spin_lock[&lock1] and reaches ldaxr; at this point, core1‘s Internal Exclusive Monitor is marked as exclusive state. In other words, core1 is in Exclusive Access state, preparing for a write operation.
- 2. Then thread2 also calls cpu_spin_lock[&lock1] and reaches ldaxr; at this point, core2‘s Internal Exclusive Monitor is marked as exclusive state; since [X0] is marked for exclusive access, it will be cached in coherent memory, which follows the MESI protocol. Thus, the data at this address will also be synchronized to the Global Monitor’s cache and Core2’s Internal Monitor’s cache, meaning that the Global Exclusive Monitor is also switched to this address data and is in exclusive state.
- 3. Next, thread1 calls the stxr operation, and it succeeds, successfully writing w2 to the [X0] address, with w1 returning 0 indicating success. At this point, core1‘s Internal Exclusive Monitor will switch from exclusive to open state. The Global Monitor will also switch from exclusive to open state.
- 4. Then thread2 also calls the stxr operation; according to the MESI protocol, core2 must snoop core1’s cache before performing the store operation. At this point, the data at this address will synchronize to the Global Monitor’s cache and core2’s Internal Monitor’s cache, and the Global exclusive Monitor will be set to open state. Since the Global exclusive Monitor cached the address data and is in open state, the stxr operation will fail;
- 5. If core2 executes ldaxr again and then performs stxr, it will succeed.
- 6. Following the program’s logic, after core2 fails the stxr operation, w1 returns 1, and the program jumps back to
<span>l2</span>to try again…
Alright, that’s all for today’s content sharing. If you found it helpful, remember to share and like!PS: On weekdays at 8:30, CSDN Corporate Recruitmentcontinues to share programmer learning and interview-related insights. Don’t miss it!
Share
Collect
Like
View