[cpp-threads] Spurious failures of try_lock{_for}({rel_time}) vs. strong try_lock{_for}({rel_time})

[Hans Boehm]

On Tue, 23 Dec 2008, Alexander Terekhov wrote:

> On Tue, Dec 23, 2008 at 7:44 AM, Hans Boehm <Hans.Boehm at hp.com> wrote:
>>
>> On Mon, 22 Dec 2008, Alexander Terekhov wrote:
>>
>>> N2800's try_lock():
>>>
>>> "Effects: Attempts to obtain ownership of the mutex for the calling
>>> thread without blocking. If ownership is not obtained, there is no
>>> effect and try_lock() immediately returns. An implementation may fail
>>> to obtain the lock even if it is not held by any other thread."
>>>
>>> N2800's try_lock_for(rel_time):
>>>
>>> "Effects: The function attempts to obtain ownership of the mutex
>>> within the time specified by rel_time. If the time specified by
>>> rel_time is less than or equal to 0, the function attempts to obtain
>>> ownership without blocking (as if by calling try_lock())."
>>>
>>> seem to contradict POSIX:
>>>
>>> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_trylock.html
>>>
>>> "The pthread_mutex_trylock() function shall be equivalent to
>>> pthread_mutex_lock(), except that if the mutex object referenced by
>>> mutex is currently locked (by any thread, including the current
>>> thread), the call shall return immediately."
>>>
>>> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_timedlock.html
>>>
>>> "Under no circumstance shall the function fail with a timeout if the
>>> mutex can be locked immediately."
>>
>> I would argue that this is a mistake in the Posix standard.  Current
>
> I disagree. Current POSIX XBD 4.10 Memory Synchronization states that
>
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_10
>
> "Unless explicitly stated otherwise, if one of the above functions
> returns an error, it is unspecified whether the invocation causes
> memory to be synchronized."
>
> So there isn't any release-acquire pairing involving failed
> try{timed}lock() in POSIX. See my interpretation of XBD 4.10 in terms
> of release-acquire pairings:
>
> http://www.decadentplace.org.uk/pipermail/cpp-threads/2005-April/000222.html
I think your interpretation is quite different from my reading of
the current Posix document.  AFAIK, the current document is still 
expressed in terms of "synchronizing memory".  The fact that trylock
may not "synchronize memory" doesn't matter, since it can be followed
by a lock acquisition and release (as it was in my example), that does
"synchronize memory".  If you reexpress Posix in terms of release-acquire
pairing, you end up with a different, more Java-like model.

In that alternate model, I think you still want to allow spurious trylock
and timedlock failures, since otherwise the alternate characterizations
of data-race from the PLDI paper are no longer equivalent, which I suspect
makes the notion of data race significantly harder to understand.  But 
that's a slightly different argument.

All of this is complicated by the fact that the Posix
"memory model" is not very clear in several respects, and we can probably
argue for a long time about what exactly it means.

Hans