Deadlocks related to scheduling

On the Oracle docs for multithreading they have this paragraph about deadlocks when trying to require a lock:

Because there is no guaranteed order in which locks are acquired, a problem in threaded programs is that a particular thread never acquires a lock, even though it seems that it should.

This usually happens when the thread that holds the lock releases it, lets a small amount of time pass, and then reacquires it. Because the lock was released, it might seem that the other thread should acquire the lock. But, because nothing blocks the thread holding the lock, it continues to run from the time it releases the lock until it reacquires the lock, and so no other thread is run.

Just to make sure I understood this, I tried to write this out in code (let me know if this is a correct interpretation):

#include <mutex>
#include <chrono>
#include <thread>
#include <iostream>

std::mutex m;

void f()
{
    std::unique_lock<std::mutex> lock(m); // acquire the lock
    std::cout << std::this_thread::get_id() << " now has the mutex\n";

    lock.unlock(); // release the lock
    std::this_thread::sleep_for(std::chrono::seconds(2)); // sleep for a while

    lock.lock(); // reacquire the lock
    std::cout << std::this_thread::get_id() << " has the mutex after sleep\n";
}

int main()
{
    std::thread(f).join(); // thread A
    std::thread(f).join(); // thread B
}

So what the quote above is saying is that the time during which the lock is released and the thread is sleeping (like the code above) is not sufficient to guarantee a thread waiting on the lock to acquire it? How does this relate to deadlocks?