:> * The cpu may reorder non-conflicting reads. A non-conflicting :> read may be reordered from *before* a write to *after* a write, :> or from *after* a write to *before* a write. :> :> This is an issue. This is the ONLY issue with intel hardware. :> :> The purpose of the locked instruction is to prevent any possibility :> of reads being reordered from to after the MP lock is released. : ^ : before ? : :So instead of releasing the lock and then writing the the locked object, :you could read from the locked object, release the lock then the read :actually happens after the lock release.

Right.

:You're not potentially spamming someone else's critical section, but actually :possibly extending your own critical section beyond the point where you've :released the lock violating your own critical section? : :-Alfred

Right. For example:

MP lock read critical data MP unlock use the critical data that you read

Pentiums have long pipelines and use a duel-issue architecture. The cpu is allowed to reorder non-conflicting instructions so the execution of this:

read instruction write instruction (release MP, not using a locked instruction) use data from read instruction

May be reordered by the cpu into this:

write instruction (release MP, not using a locked instruction) read instruction use data from read instruction

The instruction reordering is *NOT* smp-aware if you do not use a locked instruction. The reordering can occur if you read from an address that does not conflict with the write's address.

By using a dummy locked instruction, we prevent the pentium from reordering any instructions occuring before the dummy locked instruction to after:

read instruction DUMMY LOCKED INSTRUCTION write instruction (release MP lock, not using a locked instruction)

Now, obviously, the instruction reordering is heavily dependant on the pipeline and issue architecture. I am 99.9% sure that we run enough instructions in our MP unlock code such that no read instructions could possibly be reordered beyond our write instruction. But I am 0.1% unsure. We just don't know the state of the pipeline upon entry to the MPUnlock code. Plus future cpu's may use a different pipeline/issue architecture, so we cannot count on the current reordering mechanisms to stay the same (remember the 386->486 transition? Lots of people were using pipeline tricks for self modifying code and got screwed because they were violating the letter of the spec).

Thus we have that dummy locked instruction sitting there.

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message