Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #223

Re: False sharing

Show all headers | View raw

Summing up: you question was "why does not the buffer change anything"
and "why is it slow".

Why it is slow was the part I was curious in. I think we mostly covered 
the topic.


> The test program's threads update two different memory locations (that's why it it is false sharing, not sharing). Could you please explain why accesses to them should be protected by a mutex?
>
>> The 'volatile' does not guarantee it won't be, this is a common
>> misunderstanding.
>> http://origin-software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
>>
>> DS
>
> I agree that using volatile is usually harmful, however in this experiment I didn't want the compiler
behave optimally. I did verify the assembler of the loop (in one of my 
earlier posts)
and it shows that the memory accesses have not been optimised out from 
the loop.

I don't think volatile is harmful. I think what is harmful is that
people very commonly believe that 'volatile' gives some threading
guarantees. It does not give ANY WHATSOEVER, so it is a false
belief which is a source of plain errors. There are corner cases where
'volatile' is needed in the aspect of threading, I know ONE. [1]

Everything in this thread can be explained by two concepts: AS-IF
rule, and threading guarantees. The rest are technical implementation 
details, which should not be relied on.

HTH
Edek


[1] Specific to gcc, x86 (or was it x86_64?):

  if (try_lock ()) {
      var++;
  }

Back to comp.programming.threads | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: False sharing curious <curious.oskar58@gmail.com> - 2011-06-01 03:25 -0700
  Re: False sharing David Schwartz <davids@webmaster.com> - 2011-06-01 12:51 -0700
  Re: False sharing Edek <edek.pienkowski@gmail.com> - 2011-06-01 22:09 +0200

csiph-web