Re: [PATCH 07/15] Add the low level infrastructure for pthreads lock elision with TSX

[Andi Kleen <andi at firstfloor dot org>]

Rich Felker <dalias@aerifal.cx> writes:

>> I claim it's conformant yes.
>
> Unless there's some loophole that makes calling pthread_mutex_trylock
> on a regular mutex you already hold undefined behavior, I claim you're
> wrong. And I can't find any such loophole.

I would claim to be at least covered by the rationale, but ok.
Too bad it's a shall.

Can you point me to any real software impacted by this?

In the worst case we can make trylock aborting, but I'm unwilling 
to do that without evidence that it is a real problem.

>> > From a practical standpoint, I'm more worried about the cost of
>> > re-running twice every block of code that takes a mutex and does
>> > something nontrivial with it. Unless I misunderstand, elided locks
>> > should only perform well in the case where they're held for a very
>> > short time. What happens if a syscall is made during that time? Am I
>> > correct in assuming the overhead of enterring kernelspace occurs
>> > twice?
>> 
>> It doesn't.
>> 
>> The syscall aborts immediately and for an internal abort like this
>> the adaptation algorithm in the mutex lock stops eliding for some time.
>
> Does it abort before any cost is incurred, though?

A common case is that speculation happens in the time 
when you would block anyways.

That's not always the case, that is why we have adaptive locks
that stop eliding when not profitable.

>> You could abort in trylock, but that would mean no-one using trylock
>> would ever elide, which would prevent a lot of real programs from using
>> elision.
>
> Well I'm open to less-expensive solutions as long as they deliver
> conforming behavior.

It would be possible to make trylock elide only when the lock is forced
to elision explicitely, and otherwise abort. 

I would need a third per lock status bit for that and it would
complicate everything somewhat. It also would mean that all programs
that want trylock elision would need to be modified.  So it would have a
high programmer cost.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only