8 messages in org.freebsd.freebsd-smpRe: MPrellock_edx| 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 5:49:46 pm | |
| List: | org.freebsd.freebsd-smp | |
* Chee Wei Ng <scip...@yahoo.com> [000201 17:31] wrote:
Hi,
I would like to know why we need lock addl $0,0(%esp) /* see note above */ for serialization.
Could you show me an example for MP case where it may cause trouble if the above lines are not added in it?
Because I didn't see how instruction execution out of order come into the picture since before any processors enter the Critical Section, it has to acquire the mplock first, and acquire the mplock, you must 'LOCK' the bus cycle to serialize the mplock flag to be read-modify-write, so I thought here will do all the serialization as required. Unless, it could be something that may needs to serialize for access before this.
It's to ensure that memory ops scheduled _before_ the lock is released have been completed before the lock is actually released.
Otherwise out of order memory writes can occur corrupting the state of protected variables.
Imagine if a CPU releases a lock then a previously sheduled write on the _same_ cpu goes in several cycles after another processor aquires the lock.
Since we aren't using a locked cycle to release the lock, we must _at least_ insert a barrier instruction to force correct ordering.
-Alfred
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message