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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS


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?

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]