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: Torvald Riegel <triegel at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: munroesj at linux dot vnet dot ibm 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: Wed, 23 Nov 2016 15:29:22 +0100
- 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>
On Tue, 2016-11-22 at 19:40 +0100, Florian Weimer wrote:
> I'm sorry for my earlier rather destructive comments.
No worries. I guess I also wasn't clear enough in my statements (ie,
that I think the status quo is not too risky right now, instead of
thinking that the status quo will be fine forever).
> 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?
Not in the near future.
> 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?
Yes, exactly. That's why I'm not concerned about the status quo wrt TM
semantics right now; I believe we know how to implement lock elision
with sufficient confidence, and we wouldn't expose TM to non-libpthread
or arch-maintainer except through lock elision or something that uses
essentially the same approach.
Generally, current TMs don't guarantee transactions to succeed, so we
need a fallback mechanism to synchronize when transactions do not work,
and for current glibc this would mean locks (STMs or HyTMs probably
don't buy us much for glibc-internal use cases right now, at least
compared to lock elision if a decent locking scheme is possible). Thus,
we'd use lock elision on internal locks, potentially with additional
performance hints aimed at the lock elision implementation.
(There are TM modes in some implementations that guarantee completion of
restricted transactions if there is no contention. But these are really
restricted, and you need to tightly control the code that these
transactions execute, as well as avoid potential interference with other
threads (eg, false sharing). The restrictions are tighter than what
AMD's ASF proposed a few years ago, for example. Thus, these are be
special-case implementations in arch-specific code only.)
> 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.
Yes.