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

[Beman Dawes]

On Tue, Dec 23, 2008 at 1: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
> implementations on weakly ordered architectures are arguably often
> incorrect with respect to this specification.  If you want to promise
> sequential consistency for data-race-free programs in the presence of
> pthread_mutex_timedlock(), you would need lock() to have release semantics
> as well.
>
> The details are in my PPoPP 07 paper...

Have you discussed this with the POSIX folks? I'm curious to know
their reaction.

Cheers,

--Beman