Where it is undefined? There are no such precondition, I quoted it

ср, 13 сент. 2023 г., 17:43 Jonathan Wakely <cxx_at_[hidden]>:

>
>
> On Wed, 13 Sept 2023 at 16:20, Nikl Kelbon via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Postcondition of std::lock and std::try_lock:
>>
>> All of Mutexes... are locked, no deadlock occurs.
>>
>> *Effects*: All arguments are locked via a sequence of calls to lock(),
>> try_lock(), or unlock() on each argument.
>> <https://eel.is/c++draft/thread.lock.algorithm#5.sentence-1>
>>
>> The sequence of calls does not result in deadlock, but is otherwise
>> unspecified. <https://eel.is/c++draft/thread.lock.algorithm#5.sentence-2>
>>
>>
>> But in an common case, when there is a type with a mutex and you need to
>> swap it
>>
>> void swap(Type& other) {
>> std::scoped_lock l(this->mutex, other.mutex);
>> // ... do swap ...
>> }
>>
>> If addressof(other) == this same mutex will be locked, and there are no
>> precondition which blocks this usage.
>> But in fact its undefined behavior (implementation uses try_lock on
>> already locked mutex) (deadlock on msvc-stl, just ub on others)
>>
>> There are several solutions to this, either we explicitly add
>> precondition, or the implementation must handle this (then there could
>> potentially be an overhead when unlocking)
>>
>
> Or we do nothing. The precondition already exists, whether we add it
> explicitly or not.
>
> This case is the same as std::lock(m, m) which is undefined already.
>
> Being more explicit might not hurt though.
>
>
>