This is the mail archive of the
mailing list for the glibc project.
Re: Informal model for transactional memory (was: Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision)
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Rajalakshmi Srinivasaraghavan <raji at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org, aaron Sawdey <acsawdey at linux dot vnet dot ibm dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>, Steve Munroe <sjmunroe at us dot ibm dot co>, carlos at redhat dot com, adhemerval dot zanella at linaro dot org, adconrad at ubuntu dot com, wschmidt at linux dot vnet dot ibm dot com
- Date: Tue, 22 Nov 2016 14:15:11 -0600
- Subject: Re: Informal model for transactional memory (was: Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision)
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <1479771736.9880.42.camel@oc7878010663> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Tue, 2016-11-22 at 19:40 +0100, Florian Weimer wrote:
> I'm sorry for my earlier rather destructive comments.
> Do you think those of us who do not work on the implementations of the
> libothread concurrency primitives need to deal with transactional memory
> issues at all?
Well ... transactional memory is directly available to applications via builtins provided by GCC.
The PowerPC and S390 APIs are closely aligned. So any one with access to Power8/OpenPOWER, Z12, or Haswell and use it.
> The libc-internal locks do not even implement elision, and if we use
> hardware transactional memory implementations for lock elision only and
> that elision is semantically transparent, then the details would not
> matter to the rest of glibc. We just have to think about the locking.
> Is this the right approach?
> Obviously, we will have to consider once we start using transactional
> memory for anything else beside lock elision, but this seems to be
> rather far away at this point.