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: Torvald Riegel <triegel at redhat dot com>
- To: vogt at linux dot vnet dot ibm dot com
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 01 Jul 2013 15:40:19 +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> <20130701061547 dot GA5006 at linux dot vnet dot ibm dot com>
On Mon, 2013-07-01 at 08:15 +0200, Dominik Vogt wrote:
> On Fri, Jun 28, 2013 at 03:34:17AM -0400, Carlos O'Donell wrote:
> > 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.
> >
> > 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.
>
> wrlock() "may fail if: [EDEADLK] A deadlock condition was detected
> or the current thread already owns the read-write lock for writing
> or reading." So it's apparently not required to deadlock.
No but we can't return EDEADLK either because we can't detect it.
> trywrlock() is required to fail "if any thread currently holds
> rwlock (for reading or writing)". This rules out deadlocking.
>
> So, this statement is incorrect:
>
> "Compability with pthreads rwlock
>
> wrlock() / trywrlock()
> No. wrlock() is required to blocking on an already locked rwlock"
Right, the explanation is incomplete. But the end result still holds.
It's require to either deadlock or return EDEADLK. I'll update the wiki
page.