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

[Florian Weimer]

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?

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