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

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2013-06-28 at 03:34 -0400, Carlos O'Donell wrote:
> I need some consensus on this issue.
> 
> In POSIX Issue 7:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_trywrlock.html
> 
> The language for pthread_rlock_wrlock and pthread_rwlock_trywrlock says
> that it "may" deadlock, or it "may" also return EDEADLK.

Yes, it may deadlock or may return EDEADLK.  But the standard doesn't
say that it may do anything else.  With elision, we cannot know whether
we already acquired the lock (with elision) previously, so we are
neither able to deadlock nor to return EDEADLK.  If we just blindly use
elision, programs will be able to acquire the write lock twice, or hold
a write and a read lock.

> 
> My reading of this is that Torvald's guideline is incorrect:
> http://sourceware.org/glibc/wiki/LockElisionGuide#Compability_with_pthreads_rwlock
> 
> In that wrlock/trywrlock are not *required* to have a deadlock on relock
> semantic by the standard.
> 
> The same soft language of "may deadlock" is used for rdlock and thus the same
> flexibility is granted there.

This allows deadlock if the same thread already has a write lock.
Again, it's not allowed that the thread can just continue if rdlock() is
called after it already has the write lock.

> Therefore this patch #5 falls within the semantic guarantees of the standard
> and therefore can be considered correct.

I still think that we cannot use elision for the write lock part of
rwlocks without violating the semantic guarantees.