This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Chris Metcalf <cmetcalf at ezchip dot com>, Andreas Schwab <schwab at suse dot de>, Torvald Riegel <triegel at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Thomas Schwinge <thomas at codesourcery dot com>, Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Mon, 26 Jan 2015 20:49:25 -0800
- Subject: Re: [PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS
- Authentication-results: sourceware.org; auth=none
- References: <54C2BDD7 dot 7000304 at redhat dot com> <54C3B6D5 dot 3090308 at ezchip dot com> <1422119595 dot 29655 dot 42 dot camel at triegel dot csb> <54C5094A dot 8060300 at ezchip dot com> <54C51D94 dot 6030007 at ezchip dot com> <1422276280 dot 29655 dot 91 dot camel at triegel dot csb> <54C6A1DD dot 4020004 at ezchip dot com> <1422305739 dot 29655 dot 144 dot camel at triegel dot csb> <87a915b170 dot fsf at igel dot home> <54C6CF4B dot 1020600 at ezchip dot com> <54C71485 dot 8060705 at redhat dot com>
On Mon, Jan 26, 2015 at 8:31 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/26/2015 06:35 PM, Chris Metcalf wrote:
>> This version reflects Torvald's recent comments.
>>
>> 2015-01-25 Chris Metcalf <cmetcalf@ezchip.com>
>>
>> * sysdeps/nptl/internaltypes.h (to_new_sem): Define. Provides new
>> behavior for [__HAVE_64B_ATOMICS && !defined (_LP64)].
>> * nptl/sem_getvalue.c (__new_sem_getvalue): Use to_new_sem.
>> * nptl/sem_init.c (__new_sem_init): Likewise.
>> * nptl/sem_open.c (sem_open): Likewise.
>> * nptl/sem_post.c (__new_sem_post): Likewise.
>> * nptl/sem_timedwait.c (sem_timedwait): Likewise.
>> * nptl/sem_wait.c (__new_sem_wait): Likewise.
>> (__new_sem_trywait): Likewise.
>
> I'm not all that happy with this patch.
>
> For example a statically compiled application sharing a semaphore
> with a dynamically compiled application would appear to break
> under your changes and nothing you can do would fix it. They each
> have different layouts for the semaphore. This is a common problem
> when switching internal layouts (like we did from Linuxthreads to
> NPTL). I accept that you may want to make this change and that this
> particular case might be unsupportable, but I want more discussion
> on the topic.
>
> Similarly H.J's comment to change the alignment of the type
> is equally flawed as embedded sem_t's in other types would break
> other ABIs down the line. I see he's commented on that in a later
> down-thread post.
>
> As far as I can tell the only immediately kosher solution is for
> these machines, that can't use 64-bit atomics because the
> alignment of their sem_t is not correct, is to use 32-bit atomics
> (for now). The choice of 32-bit atomics in no way prevents you
> from future 64-bit atomic uses. You can switch AFAICT to another
> internal implementation at a later date.
>
> Could you switch to 32-bit atomics for 2.21 and continue to
> investigate this optimziation for 2.22?
>
What is the motivation to use 64-bit atomics for ILP32 here?
Performance or correctness?
--
H.J.