This is the mail archive of the
libc-alpha@sourceware.org
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: <f777eebe-4a7b-87d2-1281-ab605c7fce8b@linux.vnet.ibm.com> <1479394010.7146.1154.camel@localhost.localdomain> <1479771736.9880.42.camel@oc7878010663> <1479804279.7146.1280.camel@localhost.localdomain> <a5e57060-b0e0-3156-5fdd-da24a4447a5d@redhat.com> <1479807670.7146.1295.camel@localhost.localdomain> <e649d9d8-1711-fa6b-b075-7dfdaf0c18d4@redhat.com> <1479822346.7146.1313.camel@localhost.localdomain> <19d846f3-3362-f4a4-6c22-466dbdbf1d60@redhat.com> <1479833888.7146.1362.camel@localhost.localdomain> <e132812d-ec34-c69c-2aa0-c5d3f81c1bdb@redhat.com>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Tue, 2016-11-22 at 19:40 +0100, Florian Weimer wrote:
> Torvald,
>
> 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.
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/x86-transactional-memory-intrinsics.html#x86-transactional-memory-intrinsics
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/PowerPC-Hardware-Transactional-Memory-Built-in-Functions.html#PowerPC-Hardware-Transactional-Memory-Built-in-Functions
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/S_002f390-System-z-Built-in-Functions.html#S_002f390-System-z-Built-in-Functions
The PowerPC and S390 APIs are closely aligned. So any one with access to Power8/OpenPOWER, Z12, or Haswell and use it.
So yes.
>
>
> 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.
> Thanks,
> Florian
>