This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]