Assert LOCK# Pin

Encoding

EncodingOperand
zoNone

Description

The LOCK prefix asserts the processor' LOCK# pin during the duration of the prefixed instruction. This has the effect of making any memory accesses in the instruction atomic.

In a multiprocessor environment, the LOCK# pin ensures that the processor has exclusive access to any shared memory.

Beginning with the Pentium P6, when the LOCK prefix is used with memory in the core's local cache, the LOCK# pin may not always be asserted. Instead, only the core's local cache line is locked (resulting in the same effect due to cache coherency).

This prefix may only be used with the following instructions:

Even then, those instructions may only be "locked" with a memory operand. Using the LOCK prefix with those instructions when using only register operands, or on any other instruction will raise a #UD exception.

Of historical note, the infamous Pentium "F00F" bug was a bug caused by this prefix. Normally, when encountering the invalid encoding of the CMPXCHG8B instruction (one useing a register operand), the processor would raise a #UD exception. However, when prefixed with LOCK, the LOCK# pin would be asserted when reading the exception handler. As locked reads must be paired with a write, the processor's bus interface would forbid all other memory access until the next write, but the paired write would not arrive. This would ultimately lock up the processor's external bus and prevent any other memory access. The only way to recover from this is to reset the processor.

Operation

public void LOCK()
{
    AssertLockThroughThisInstruction();
}

Flags Affected

None.

Exceptions

Real-Address Mode

#UD

Virtual-8086 Mode

#UD

Protected Mode

#UD

Compatibility Mode

#UD

Long Mode

#UD