| From | Sent On | Attachments |
|---|---|---|
| Chee Wei Ng | Feb 1, 2000 5:05 pm | |
| Alfred Perlstein | Feb 1, 2000 5:49 pm | |
| Matthew Dillon | Feb 1, 2000 6:30 pm | |
| Alfred Perlstein | Feb 1, 2000 7:20 pm | |
| Alfred Perlstein | Feb 1, 2000 7:24 pm | |
| Chee Wei Ng | Feb 1, 2000 8:08 pm | |
| Matthew Dillon | Feb 1, 2000 8:22 pm | |
| Chee Wei Ng | Feb 1, 2000 8:28 pm |
| Subject: | Re: MPrellock_edx | |
|---|---|---|
| From: | Alfred Perlstein (bri...@wintelcom.net) | |
| Date: | Feb 1, 2000 7:20:45 pm | |
| List: | org.freebsd.freebsd-smp | |
* 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 uses.
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 an issue.
* 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.
^ 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.
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
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message





