Betrayed by a bitfield [LWN.net]

Betrayed by a bitfield

Posted Feb 7, 2012 19:21 UTC (Tue) by chrisV (subscriber, #43417)
In reply to: Betrayed by a bitfield by BenHutchings
Parent article: Betrayed by a bitfield

Are you telling me that you have actually run a test case compiled with the -pthread option which exhibits this problem? If not, I just don't believe you because I have written shed loads of multi-threaded code using POSIX threads which has never encountered a false sharing problem of this kind.

If you run a test case compiled with the -pthread flag which exhibits this problem then this is an egregious failure on the part of the threading implementation of gcc and you should post a bug. (It is far more serious than the non-standards complying kernel code.)

(Log in to post comments)

Betrayed by a bitfield

Posted Feb 7, 2012 19:36 UTC (Tue) by chrisV (subscriber, #43417) [Link]

And since you refer to "none of the options you are suggesting makes a slight difference", can you also clarify whether you mean you have run a test case demonstrating false sharing even in the case of 64-bit scalars, and/or even in the case of assembly instructions which should have forced synchronization?

Betrayed by a bitfield

Posted Feb 15, 2012 17:01 UTC (Wed) by cbf123 (guest, #74020) [Link]

I just tested with gcc version 4.3.2 (Wind River Linux Sourcery G++ 4.3-85) for powerpc. Building the test app (the volatile version) as "gcc x.c -c -m64 -pthread" resulted in the following code, which clearly shows a 64-bit read/write cycle.

0000000000000000 <.wrong>:
   0:   fb e1 ff f8     std     r31,-8(r1)
   4:   f8 21 ff c1     stdu    r1,-64(r1)
   8:   7c 3f 0b 78     mr      r31,r1
   c:   f8 7f 00 70     std     r3,112(r31)
  10:   e9 3f 00 70     ld      r9,112(r31)
  14:   e8 09 00 08     ld      r0,8(r9)
  18:   39 60 00 01     li      r11,1
  1c:   79 60 f8 2c     rldimi  r0,r11,31,32
  20:   f8 09 00 08     std     r0,8(r9)
  24:   e8 21 00 00     ld      r1,0(r1)
  28:   eb e1 ff f8     ld      r31,-8(r1)
  2c:   4e 80 00 20     blr

Betrayed by a bitfield

Posted Feb 16, 2012 20:21 UTC (Thu) by chrisV (subscriber, #43417) [Link]

Any chance you could file a bug on this one? It is not so bad if the non-standard use of volatile has this effect (although no doubt still very annoying to the kernel developers), but it seems to me to be something else when the code happens to be POSIX-conforming code and corrupts memory locations.

(Yes I have seen the argument in papers in the early proposals for the C/C++ threading model that "memory location" is ambiguous in Base Definitions, section 4.11, of the SUS, and could refer to a machine's natural word size rather than individual scalars, and so C11/C++11 now explicitly states that "memory location" in its equivalent wording means any scalar or bitfield, but that is a completely perverse construction of the SUS as it makes POSIX threads completely useless as a standard, bringing threading back to individual non-standard ABIs.)