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 7:24:10 pm | |
| List: | org.freebsd.freebsd-smp | |
* Chee Wei Ng <scip...@yahoo.com> [000201 19:00] wrote:
Hi Alfred,
--- Alfred Perlstein <bri...@wintelcom.net> wrote:
* 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
In this case, what you mean is that in order to update all the modified memory for previous locked Critical Section, the barrier must be inserted for that processor, right?
For example,
Initial value of A = 0xdeadc0de;
Processor 1 Processor 2 ----------- ----------- MPgetlock_edx(mplock); A = 0; MPrellock_edx(mplock); MPgetlock(mplock); read A; MPrellock(mplock);
Suppose we do not have barrier instruction at MPrellock. According to your explanation: 1. The 'LOCK' instruction executed in MPgetlock at processor 2 after processor 1 released the mplock will not serialize the value of A, so when processor 2 got the mplock and read A, it is possible to read 0xdeadc0de instead of 0. 2. The write of A and mplock will not be in order, i.e. it could be mplock == 0 and A == 0xdeadc0de, after processor 1 released mplock and processor 2 wanted to acquire the mplock.
The processor 1 might have follow the write order but the processor 2 will see two values in out of order way. i.e. mplock will be updated before A.
That's why processor 2 thought that it has the mplock and it's safe to read A, but infact it is not.
Is this what you mean?
I'm wrong, see Matt Dillon's answer.
-Alfred
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message