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

Groups > comp.programming.threads > #221 > unrolled thread

Re: False sharing

Back to article view | Back to comp.programming.threads

Contents

  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

#221 — Re: False sharing

On Tuesday, 31 May 2011 22:12:47 UTC+1, David Schwartz  wrote:
> On May 30, 4:26 am, curious <curious...@gmail.com> wrote:
> 
> > I expected it to run much faster when the char buffer[128] would not
> > be commented out. However it seems that it does not affect the
> > runtime. For both scenarios I get almost identical results.
> 
> Your code is broken and may not be testing anything. You are using
> POSIX threads, which requires that mutexes be used when an object may
> be modified concurrently by two or more threads. You have defined your
> WorkArea such that worker1 and worker2 are parts of the very same
> object. So you must modify them under the protection of a mutex. Your
> false sharing may just be optimized away.

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.

[toc] | [next] | [standalone]

#222

On Jun 1, 3:25 am, curious <curious.oska...@gmail.com> wrote:

> 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?

They don't access two different memory locations, they access two
parts of the same object which the compiler may or may not have
assigned two memory addresses to. Nothing prevents the compiler from
completely optimizing out memory accesses, even with 'volatile'.

> > 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-almo...

> 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.

It shows that memory accesses were not optimized out BY THE COMPILER.
Any optimization the compiler could do can also, at least in
principle, be done by any other component of the system. If this is a
platform-specific investigation, based on attributes of the specific
platform you are testing on, you have to at least tell us what the
platform is.

DS

[toc] | [prev] | [next] | [standalone]

#223

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++;
  }

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web