Assert LOCK# Pin




The LOCK prefix asserts the processor's LOCK# pin for 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 using 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.


public void LOCK()

Flags Affected



Real-Address Mode


Virtual-8086 Mode


Protected Mode


Compatibility Mode


Long Mode