Messages in this thread | | | Subject | Re: spin_unlock optimization(i386) | Date | Thu, 25 Nov 1999 10:00:41 -0800 | From | Erich Boleyn <> |
| |
Oliver Xymoron <oxymoron@waste.org> wrote:
> What you can't be sure of is that things after the write haven't already > occurred - speculative execution of reads past the end of a critical > section or into the beginning of another: > > CPU 1 CPU2 > write data,shared > write 0,lock > bts lock > jc 2 > read shared > > Here, shared is guaranteed to be written in program order, that is before > lock. But we have no guarantee that CPU2's read doesn't speculatively > happen before the lock grab, which means causality here is not preserved.
All reads/writes happen in program order with respect to the observed memory image.
If anything changes to the inputs of a speculatively executed instruction prior to becoming committed state, then that work is thrown out. There is no causality violation.
In specific, since "lock" and "shared" observed in order, and since IA32 executes in program order with respect to the observed memory image, then when the change to "lock" is observed for the "bts lock", the change to "shared" MUST be.
> Which is ok, of course, since we need to force atomicity of the lock grab > anyway and the way to do that is with the LOCK prefix, which ends up > serializing memory access.
I believe LOCK# doesn't serialize memory accesses, it just prevents other bus readers/writers from getting access to that location for the duration of the operation in question.
It also doesn't need to, since the program is executed are done AS IF in order with respect to the observed memory image.
-- Erich Boleyn PMD Architecture <esboleyn@ichips.intel.com>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |