Carlos O'Donell - Re: [PATCH] Only use 64b atomics in semaphores if long int is 64b. (original) (raw)

This is the mail archive of the libc-alpha@sourceware.orgmailing list for the glibc project.

• From: "Carlos O'Donell"
• To: Torvald Riegel , GLIBC Devel
• Cc: "Joseph S. Myers" , Chris Metcalf , "H.J. Lu"
• Date: Sun, 01 Feb 2015 18:56:48 -0500
• Subject: Re: [PATCH] Only use 64b atomics in semaphores if long int is 64b.
• Authentication-results: sourceware.org; auth=none
• References: <1422647712 dot 16670 dot 41 dot camel at triegel dot csb>

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.