Re: [PATCH] Only use 64b atomics in semaphores if long int is 64b.

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/30/2015 02:55 PM, Torvald Riegel wrote:
> This patch is another attempt at fixing this.  It uses Josephs
> suggestion for a new flag, SEM_USE_64B_ATOMICS, which is set to 1 iff
> __HAVE_64B_ATOMICS != 0 and defined (__LP64__).  This is meant to
> capture the condition that we need "long int" to be a 8-byte-sized type.
> 
> This does expect that an 8B-sized long int will also be 8B-aligned.  Do
> we support any arch where this isn't true?
> 
> Joseph also suggested to !SHLIB_COMPAT (libpthread, GLIBC_2_0,
> GLIBC_2_22)) to enable this on archs for which support has been added
> starting with 2.22.  I'm not entirely sure how this machinery works
> (specifically, where/how an arch defines what it's first supported
> version is), but I'll prepare a patch that uses this in the struct
> new_sem definition and tries to merge the many bits/semaphore.h headers
> into a generic one (so that new archs would pick up this one
> specifically).
> 
> Chris' patch for at-runtime realignment of the data can still be added
> during the 2.22 cycle.  I talked a bit about it with Carlos offline, and
> one concern he had was violating the aliasing rules in the language, and
> thus potentially making the compiler do funny things (hence the
> hesitation to use this for 2.21).
> 
> Tested on x86_64-linux and i686-linux.
> 
> OK?
> 
> Carlos, if OK, do you want this for 2.21, or for 2.22 (and let all
> affected archs just set __HAVE_64B_ATOMICS to 0 as MIPS has done
> already)?

Please aim for 2.22 as it needs a review of the SHLIB_COMPAT to make
sure it does what we intend.

Cheers,
Carlos.