This is the mail archive of the
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
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.