This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 05/14] Add lock elision to rwlocks
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 2 Jul 2013 15:30:13 +0200
- Subject: Re: [PATCH 05/14] Add lock elision to rwlocks
- References: <1372398717-16530-1-git-send-email-andi at firstfloor dot org> <1372398717-16530-6-git-send-email-andi at firstfloor dot org> <51CD3C79 dot 2040906 at redhat dot com> <1372685886 dot 22198 dot 3456 dot camel at triegel dot csb> <20130702075527 dot GA7693 at linux dot vnet dot ibm dot com> <1372764701 dot 22198 dot 4435 dot camel at triegel dot csb>
- Reply-to: vogt at linux dot vnet dot ibm dot com
Again, please _do_ _not_ cc me on replies, I read the list.
On Tue, Jul 02, 2013 at 01:31:41PM +0200, Torvald Riegel wrote:
> On Tue, 2013-07-02 at 09:55 +0200, Dominik Vogt wrote:
> > On Mon, Jul 01, 2013 at 03:38:06PM +0200, Torvald Riegel wrote:
> > > With elision, we cannot know whether we already acquired the
> > > lock (with elision) previously,
> >
> > Please note that this way of speaking about elision is incorrect
> > and has already lead to wrong results in your analysis:
> >
> > You either acquire the lock _or_ elide it.
>
> At the level of the user program, we always (virtually) acquire the
> lock. If a program sticks to what's defined by the respective
> standards, a program cannot detect whether elision was used during a
> lock acquisition or not. Given that we've been talking about semantics
> required by the standard in this thread, I think reasoning on the level
> of the user program is the right thing to do.
Yes, it's the right thing to do. What you have not got yet is
that from the point of view of the user program, any calls
_inside_ a transaction (i.e. nested elided locks) have never been
executed at all if the transaction aborts. And calls that have
never been executed do not have to follow POSIX semantics.
Only if the outermost transaction completes these calls have to
follow POSIX semantics given the state of the machine at the time
the transaction completes. And at that time there will never be
another thread that competes for that lock, because either
transactions has aborted before that.
> The details we have been discussing are about cases where *one* thread
> tries to acquire the write lock twice, or acquired both a read and a
> write lock (on the same rwlock). This isn't about other threads at all.
I recommend you carefully read what I've written from the
beginning again and try to understand what it means. You're so
caught in your own opinoins that you fail to look at the task from
a different point of view.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany