Trouble understanding the unique_lock - c++

Question

I have some trouble understanding the unique_lock and condition_variable in the code below.
#define _GLIBCXX_USE_NANOSLEEP
#include <chrono>
#include <mutex>
#include <thread>
#include <iostream>
#include <condition_variable>
using namespace std;
mutex m;
int i=1;
condition_variable cv;
void funcA()
{
cout << "FuncA Before lock" << endl;
unique_lock<mutex> lk(m);
cout << "FuncA After lock" << endl;
while(i != 2) { cv.wait(lk); }
//std::chrono::milliseconds dura(500);//make sure thread is running
//std::this_thread::sleep_for(dura); //this_thread::sleep_for(dura);
cout << "FuncA After sleep" << endl;
lk.unlock();
cv.notify_all();
}
void funcB()
{
cout << "FuncB Before lock" << endl;
unique_lock<mutex> lk(m);
cout << "FuncB After lock" << endl;
while(i != 1) { cv.wait(lk); }
//std::chrono::milliseconds dura(500);//make sure thread is running
//std::this_thread::sleep_for(dura); //this_thread::sleep_for(dura);
cout << "FuncB After sleep" << endl;
++i;
lk.unlock();
cv.notify_all();
}
int main(int argc, char* argv[])
{
auto a = thread(funcA), b=thread(funcB);
a.join(), b.join();
return 0;
}
As per https://en.cppreference.com/w/cpp/thread/unique_lock/unique_lock (when the constructor is called with a mutex) the constructor locks the associated mutex by calling m.lock()
Let us say, threadA/funcA gets scheduled first by the operating system. So, the following lines will get executed
cout << "FuncA Before lock" << endl;
unique_lock<mutex> lk(m);
cout << "FuncA After lock" << endl;
while(i != 2) { cv.wait(lk); }
Now, threadA has the mutex since the constructor for the unique_lock has called lock on it. However, since i!=2, the thread will stay in the while-loop waiting to be notified by the other thread.
Now, let us say the operating system switches the threads and funcB is called.
cout << "FuncB Before lock" << endl;
unique_lock<mutex> lk(m);
Now, this thread should get stuck here on the second line right? Because mutex m is already owned by threadA (since it has called m.lock() on it), and therefore the m.lock() call by unique_lock constructor should block since the mutex is not available.
So, there's a deadlock? The threadA is waiting in the infinite loop waiting for i to be incremented to 2, whereas threadB is waiting for the mutex owned by threadA.
However, nothing like that happens, and the code works fine.