This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [RFC] nptl: use compare and exchange for lll_cond_lock
- From: Torvald Riegel <triegel at redhat dot com>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Thu, 25 Sep 2014 20:00:08 +0200
- Subject: Re: [PATCH] [RFC] nptl: use compare and exchange for lll_cond_lock
- Authentication-results: sourceware.org; auth=none
- References: <5421B1C2 dot 9020509 at linux dot vnet dot ibm dot com>
On Tue, 2014-09-23 at 14:45 -0300, Adhemerval Zanella wrote:
> While checking the generated code and macros used in generic lowlevellock.h,
> I noted powerpc and other arch uses uses a compare and swap instead of a plain
> exchange value on lll_cond_lock.
> I am not really sure which behavior would be desirable, since as far I could
> they will have both the same side effects (since lll_cond_lock, different
> from lll_lock, does not hold value of '1').
What do you mean by "[the function] does not hold value of '1'"?
> So I am proposing this patch to sync default implementation for what mostly
> architectures (ia64, ppc, s390, sparc, x86, hppa) uses for lll_cond_lock. I see
> that only microblaze and sh (I am not sure about this one, I not well versed in
> its assembly and I'm being guided by its comment) used the atomic_exchange_acq
> instead.
I think both versions work from a correctness POV, but doing an
unconditional exchange should be the right thing to do.
The default implementation of __lll_lock_wait will test if the futex
variable equals 2, and if not, do an exchange right away before running
the FUTEX_WAIT syscall. So if the CAS that you propose fails, the next
thing that will happen is an exchange. Thus, it seems that we should do
the exchange right away.
Thoughts?