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: Rich Felker <dalias at aerifal dot cx>
- 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, 01 Jul 2013 22:08:52 +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> <1372685886 dot 22198 dot 3456 dot camel at triegel dot csb> <20130701143912 dot GY29800 at brightrain dot aerifal dot cx>
On Mon, 2013-07-01 at 10:39 -0400, Rich Felker wrote:
> 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.
Yes, probably. You're right that it isn't exactly clear due to the
restriction to "other" threads in the first sentence. On the other
hand, it doesn't ever mention that "recursive" acquisition is a possible
outcome.
Furthermore, rdlock must not acquire a read lock if "a writer" holds the
lock (ie, no distinction made with other threads):
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_tryrdlock.html
If we would use elision for write locks, we couldn't ever detect this
case, and thus couldn't guarantee correct behavior. The required
behavior is deadlock or returning EDEADLK.
Thus, even if POSIX would resolve the case of just wrlock in favor of
recursive acquisition, we'd still have the read/write lock issue that
prevents us from using elision for writelocks.
Torvald