 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/2011 11:49 PM, Darren New wrote:
> On 9/12/2011 1:13, Invisible wrote:
>> (Think about it; if you did, every multi-threaded application ever
>> written
>> would suddenly break when run on a multi-chip or multi-core setup.)
>
> Not really. You have no more likelihood of breaking because of lack of
> memory barriers than you have of breaking because you've cached
> something in a register during a task switch.
>
> The compiler just has to write memory barrier instructions out when you
> access a volatile variable. That's why the keyword is there.
If you cache something in a register that you shouldn't have, your
application will break on a uniprocessor system. And you'll notice this,
and fix it.
If the hardware didn't enforce cache coherence, applications would work
perfectly on a uniprocessor and then break spectacularly on a
multiprocessor. This doesn't happen, ergo the hardware is enforcing
cache coherence.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/13/2011 1:31, Invisible wrote:
> If you cache something in a register that you shouldn't have, your
> application will break on a uniprocessor system. And you'll notice this, and
> fix it.
Right.
> If the hardware didn't enforce cache coherence, applications would work
> perfectly on a uniprocessor and then break spectacularly on a
> multiprocessor.
In what way would it break, given the OS inserts a memory barrier when it
switches tasks?
I.e., in what case would you expect a variable written to memory followed
immediately by a nondeterministic task switch to give you different results
on a multi vs uni processor? In what case would you expect a variable cached
in a register to give you different results during a task switch on a multi
vs uni processor?
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> If the hardware didn't enforce cache coherence, applications would work
>> perfectly on a uniprocessor and then break spectacularly on a
>> multiprocessor.
>
> In what way would it break, given the OS inserts a memory barrier when
> it switches tasks?
It's not about task switches, it's about two tasks running on different
cores trying to communicate through memory. If the cores didn't
automatically synchronise their caches, that wouldn't work at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/2011 1:56, Invisible wrote:
> It's not about task switches, it's about two tasks running on different
> cores trying to communicate through memory. If the cores didn't
> automatically synchronise their caches, that wouldn't work at all.
You're missing my point. If it doesn't work with two cores, it doesn't work
with one core either.
If it's automatic, why do x86 CPUs have memory fence instructions?
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/09/2011 05:48 PM, Darren New wrote:
> On 9/14/2011 1:56, Invisible wrote:
>> It's not about task switches, it's about two tasks running on different
>> cores trying to communicate through memory. If the cores didn't
>> automatically synchronise their caches, that wouldn't work at all.
>
> You're missing my point. If it doesn't work with two cores, it doesn't
> work with one core either.
Yes it does. Because if two tasks run on the same core, they share the
same cache. It's not possible to have two caches out of sync unless
there's actually, you know, *two caches*.
> If it's automatic, why do x86 CPUs have memory fence instructions?
I'm guessing that's for performance, not correctness.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/2011 13:54, Orchid XP v8 wrote:
>> If it's automatic, why do x86 CPUs have memory fence instructions?
> I'm guessing that's for performance, not correctness.
http://software.intel.com/en-us/forums/showthread.php?t=65071
It appears at first google that you are correct. On second google,
http://siyobik.info/main/reference/instruction/LFENCE
I think what's happening is that I might write instructions that store
things out of order, so I store something in a memory address, then store a
pointer to that address some place you will look. On the x86 at least, the
memory fence is necessary to make sure that I have stored the data before I
have stored the pointer to it. You will always fetch the most recent pointer
I have stored, but executing "store data ; store pointer" might store the
pointer before the data without a fence. So it's not caches of main memory
but caches of instruction results that's the issue I was thinking of.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/2011 13:54, Orchid XP v8 wrote:
> I'm guessing that's for performance, not correctness.
On third google:
http://bartoszmilewski.wordpress.com/2008/11/05/who-ordered-memory-fences-on-an-x86/
That pretty much summarizes it, I guess.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 03:03 AM, Darren New wrote:
> It appears at first google that you are correct.
I usually am. And yet people still seem surprised...
> You will always fetch the
> most recent pointer I have stored, but executing "store data ; store
> pointer" might store the pointer before the data without a fence.
It took me a few minutes contemplation to figure out why cache coherence
doesn't solve that problem.
[OK, I can't keep a straight face any more. Of *course* I'm not always
right! LOLZ. Sometimes I feel like I'm right a lot more often than I get
credit for though...]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 03:06 AM, Darren New wrote:
> On third google:
>
> http://bartoszmilewski.wordpress.com/2008/11/05/who-ordered-memory-fences-on-an-x86/
>
> That pretty much summarizes it, I guess.
...and /this/ is why high-level concurrent programming frameworks are a
huge, huge win for writing reliable code. o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/16/2011 1:40, Invisible wrote:
> ...and /this/ is why high-level concurrent programming frameworks are a
> huge, huge win for writing reliable code. o_O
Well, of course. Libraries of working code are always better than
hand-rolled stuff.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
