Re: [PATCH 05/14] Add lock elision to rwlocks

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2013-07-02 at 15:30 +0200, Dominik Vogt wrote:
> 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.

I started working on transactional memory about 8 years ago, so I can
assure you that I do understand a bit about it :)

> And calls that have
> never been executed do not have to follow POSIX semantics.

But you do execute code you shouldn't be executing, and it can contain
commit calls (eg, _xcommit() in case of TSX).  Another example would be
hitting a branch that unlocks the lock that didn't guarantee the POSIX
semantics that it should guarantee.  So if you execute such code, the
misbehavior very much becomes visible.  You can't prevent this from
happening (ie, locks don't control the code that uses them), so you need
to be conservative.

Another case that's worth thinking about is what happens if the HTM in
question allows for nonspeculative operations (e.g., like AMD's ASF
does), or allows for suspending and resuming a transaction.  If you want
to make use of this (e.g., for malloc calls, nontransactional
synchronization, etc.), it makes a difference whether the nonspeculative
code can assume to be in a consistent execution or not.

There's a difference between speculative execution just for concurrency
control (ie, synchronizing between transactions) and speculative
execution that might do things that should never happen.  In general, in
the latter case, you need to have tight control over when you commit,
which typically requires some kinds of commit hooks or control/analysis
of the code you execute.

> > 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.

Hmm.  That sounds like too much speculation to me ;)