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

["Carlos O'Donell" <carlos at redhat dot com>]

On 07/01/2013 10:39 AM, 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.

After reading the trywrlock case which says "any thread", I'm almost
certain this is a defect in the standard.

Either way, given the language of "any thread" vs. "other thread" would
mean that for elision trywrlock would have to fail, while wrlock would
succeed, which seems sufficiently odd to raise a red flag.

>> 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.

Right, which would make wrlock's behave more like NORMAL-type locks
and require either deadlock detection or an outright deadlock on
relock from the same thread.

Cheers,
Carlos.