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: Rich Felker <dalias at aerifal dot cx>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>
- Date: Mon, 1 Jul 2013 10:39:12 -0400
- 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> <1372685886 dot 22198 dot 3456 dot camel at triegel dot csb>
On Mon, Jul 01, 2013 at 03:38:06PM +0200, Torvald Riegel wrote:
> 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.
The relevant text is:
"The calling thread acquires the write lock if no other thread
(reader or writer) holds the read-write lock rwlock. Otherwise,
the thread shall block until it can acquire the lock. The calling
thread may deadlock if at the time the call is made it holds the
read-write lock (whether a read or write lock)."
I don't think this is at all clear about the possibilities. The first
sentence seems to imply (by use of the word other) that the lock is
acquired (recursively?) if the thread itself already holds the lock,
since "no _other_ thread holds" it. But the third sentence allows it
to deadlock. And then the "ERRORS" text contradicts this with a third
possibility, a "may fail" with EDEADLK.
A bug report to the Austin Group is probably called for.
> 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.
The first sentence above seemed to allow or even require this
behavior, but I do not think it's the intent. The word "other" is
probably an error.
Rich