05.02.2013 Views

ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition

ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition

ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

The System Level Programmers’ Model<br />

DSB<br />

ISB<br />

MCR p15, 0, Rx, c1, c0, c0 ; change FI bit in the SCTLR<br />

DSB<br />

ISB<br />

Implementation can define other sequences <strong>and</strong> circumstances that permit the SCTLR.FI bit to be changed.<br />

When interrupt latency is reduced, this can result in reduced performance overall. Examples of methods that<br />

might be used to reduce interrupt latency are:<br />

disabling Hit-Under-Miss functionality in a processor<br />

the ab<strong>and</strong>oning of restartable external accesses.<br />

These choices permit the processor to react to a pending interrupt faster than would otherwise be the case.<br />

A low interrupt latency configuration permits interrupts <strong>and</strong> asynchronous aborts to be taken during a<br />

sequence of memory transactions generated by a load/store instruction. For details of what these sequences<br />

are <strong>and</strong> the consequences of taking interrupts <strong>and</strong> asynchronous aborts in this way see Single-copy atomicity<br />

on page A3-27.<br />

<strong>ARM</strong> deprecates any software reliance on the behavior that an interrupt or asynchronous abort cannot occur<br />

in a sequence of memory transactions generated by a single load/store instruction to Normal memory.<br />

Note<br />

A particular case that has shown this reliance is load multiples that load the stack pointer from memory. In<br />

an implementation where an interrupt is taken during the LDM, this can result in corruption of the stack<br />

pointer.<br />

B1.6.8 Wait For Event <strong>and</strong> Send Event<br />

A multiprocessor operating system requires locking mechanisms to protect data structures from being<br />

accessed simultaneously by multiple processors. These mechanisms prevent the data structures becoming<br />

inconsistent or corrupted if different processors try to make conflicting changes. If a lock is busy, because<br />

a data structure is being used by one processor, it might not be practical for another processor to do anything<br />

except wait for the lock to be released. For example, if a processor is h<strong>and</strong>ling an interrupt from a device it<br />

might need to add data received from the device to a queue. If another processor is removing data from the<br />

queue, it will have locked the memory area that holds the queue. The first processor cannot add the new data<br />

until the queue is in a consistent state <strong>and</strong> the lock has been released. It cannot return from the interrupt<br />

h<strong>and</strong>ler until the data has been added to the queue, so it must wait.<br />

Typically, a spin-lock mechanism is provided for these circumstances:<br />

A processor requiring access to the protected data attempts to obtain the lock using single-copy<br />

atomic synchronization primitives such as the <strong>ARM</strong> Load-Exclusive <strong>and</strong> Store-Exclusive operations<br />

described in Synchronization <strong>and</strong> semaphores on page A3-12.<br />

If the processor obtains the lock it performs its memory operation <strong>and</strong> releases the lock.<br />

B1-44 Copyright © 1996-1998, 2000, 2004-2008 <strong>ARM</strong> Limited. All rights reserved. <strong>ARM</strong> DDI 0406B

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!