This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision

On 11/22/2016 10:41 AM, Torvald Riegel wrote:

And unlike code
using incorrect synchronization or legacy atomics, we don't have a path
towards the C11 model because what the code does is completely outside
it, so there's no argument on favor of gradual/partial conversion.

The HW transaction has to synchronize with nontransactional code.  We're
obviously going to use the C11 model for nontransactional code.  Thus,
it cannot be unrelated.  It's true that we don't have a detailed
description of how HW transactions *extend* the C11 model, but it
clearly would be an extension because it simply has to fit in there and
it will use the same underlying mechanisms.

One can also think about it this way: There is nontransactional code
that has to use atomics (because there are concurrent accesses from
other nontransactional code as well as transactional code).  So we are
going to use atomics there.  Then, even if just for consistency, we're
going to use (relaxed MO) atomic accesses too for all other concurrent
accesses to the same data.

The counter-argument to that this is until we have a specification of how this kind of transactional memory works, we don't know what it means if an object is accessed from both a transaction and and other non-transactional code, and what external constraints are needed to make such access valid (if any). There are some really scary examples from early transaction memory implementations.

But come to think of it, the core issue hasn't got to do much with atomics at all. It's just about how the transactional memory implementation works. So I don't really have any strong opinions here.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]