Informal model for transactional memory (was: Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision)

[Steven Munroe]

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
>