Re: [PATCH] Don't rely on having LP64 in semaphores if 64b atomic ops are available.

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2015-01-22 at 10:29 -0800, H.J. Lu wrote:
> On Thu, Jan 22, 2015 at 10:24 AM, Torvald Riegel <triegel@redhat.com> wrote:
> > This attempts to fix an issue in the new semaphore implementation for
> > archs that provide 64b atomic ops but do not use an LP64 data model.
> > This affects MIPS N32 ABI and x32 too I guess.
> >
> > Steve, can you test this patch please?  I'll do the same on x86_64-linux
> > in the meantime.
> >
> > Also, do we already have any information on which data models we
> > support?  I reckon LP64 and ILP32?, or others as well?  I'd like to add
> > a comment to atomic.h, and if we have such information already, I'd just
> > point to it.
> >
> >
> > 2015-01-22  Torvald Riegel  <triegel@redhat.com>
> >
> >         * nptl/sem_post.c (__new_sem_post): Don't rely on an LP64 data model.
> >         * nptl/sem_waitcommon.c (__sem_wait_cleanup, __new_sem_wait_fast,
> >         __new_sem_wait_slow): Likewise.
> >         * sysdeps/nptl/internaltypes.h (struct new_sem): Likewise.
> 
> Do we really need int64 for the "data" field internally?

First, there's an option to use either 32b or 64b atomic operations.  If
the latter are available and not significantly more expensive than 32b
atomics, using 64b is more efficient.

If we want to use 64b atomics, we need to operate on 64b data,
eventually.  We could try to use adjacent uint32 as one uint64 and
access the uint32 separately where possible, but such mixing of
overlapping atomic ops isn't defined by C11, and we shouldn't use it.
If we don't, yet still try to use adjacent uint32 as underlying storage,
the code won't become simpler.

Thus, I think using uint64 as underlying type makes sense.  Do you see
any disadvantages?