Proposed resolution:

This wording is relative to N4700.

1. Change [thread.lock.algorithm] as indicated:

   template <class L1, class L2, class... L3> int try_lock(L1&, L2&, L3&...);
   

   -1- Requires: […]

   -2- Effects: Calls try_lock() for each argument in order beginning with the first until all arguments have been processed or a call to try_lock() fails, either by returning false or by throwing an exception. If a call to try_lock() fails, unlock() shall beis called for all prior arguments and there shall bewith no further calls to try_lock().

   […]

   template <class L1, class L2, class... L3> void lock(L1&, L2&, L3&...);
   

   -4- Requires: […]

   -5- Effects: All arguments are locked via a sequence of calls to lock(), try_lock(), or unlock() on each argument. The sequence of calls shalldoes not result in deadlock, but is otherwise unspecified. [Note: A deadlock avoidance algorithm such as try-and-back-off must be used, but the specific algorithm is not specified to avoid over-constraining implementations. — end note] If a call to lock() or try_lock() throws an exception, unlock() shall beis called for any argument that had been locked by a call to lock() or try_lock().

[ 2018-3-17 Adopted in Jacksonville ]

[ 2017-11 Albuquerque Wednesday night issues processing ]

Moved to Ready

[thread.lock.algorithm] says:

"If a call to try_lock() fails, unlock() shall be called for all prior arguments and there shall be no further calls to try_lock()."

We try to use "shall" for requirements on the user (e.g. as in the previous paragraph) which is absolutely not what is meant here.