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

[Alexander Terekhov]

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

Judging from the draft and also

http://www.hpl.hp.com/techreports/2008/HPL-2008-56.pdf

the primary intent behind introduction of spurious failures was to
make unlock()->try_lock{_for}({rel_time}) "synchronize with"
conditionally ("If try_lock() returns true, prior unlock() operations
on the same object synchronize with (1.10) this operation.").

But why insist on spurious failures for try_lock{_for}({rel_time})
instead of simply saying that these operations provide the effect of
atomic_thread_fence(memory_order_acquire) if mutex ownership is
obtained, otherwise no fence effect
(atomic_thread_fence(memory_order_relaxed) if you like)?

regards,
alexander.