> 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/