[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: spin_unlock optimization(i386)

Oliver Xymoron <> 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.066 / U:22.780 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site