This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Informal model for transactional memory (was: Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel 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: Tue, 22 Nov 2016 19:40:04 +0100
- Subject: 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>
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