* Matthew Dillon <dil...@apollo.backplane.com> [000201 18:56] wrote:
I discussed this issue with Linus after someone from the linux kernel
group brought it up. Basically we have adopted the same thing that linux
Under Intel, the following is true:
* Writes are buffered but are committed to memory in the same
order they were issued. Thus write<->write conflicts are not
* Speculative reads may occur, but they occur from main memory
into the L1 cache and thus still adhere to L1 cache protocols.
Thus speculative reads are not an issue.
* 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.
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.
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?
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message