How can pthread_cond_wait() be decoupled with mutex?

I've been thinking about the logic behind condition variable for a while, and getting comfortable with most common questions associated with it.

Basically, if We do something like:

mutex.lock()
while(!predicate()){
    mutex.unlock();
    pthread_cond_wait(&cv); // with mutex decoupled, no mutex is passed in I guess.
    mutex.lock();
}
mutex.unlock();

The window between unlock() and wait() is something we need to eliminate, and that's pretty much why cv exists in the first place.

Then I found this:

> ### Features of Mutexes and Condition Variables
>
> It had been suggested that the mutex acquisition and release be
> decoupled from condition wait. This was rejected because it is the
> combined nature of the operation that, in fact, facilitates realtime
> implementations. Those implementations can atomically move a
> high-priority thread between the condition variable and the mutex in a
> manner that is transparent to the caller. This can prevent extra
> context switches and provide more deterministic acquisition of a mutex
> when the waiting thread is signaled. Thus, fairness and priority
> issues can be dealt with directly by the scheduling discipline.
> Furthermore, the current condition wait operation matches existing
> practice.

(https://linux.die.net/man/3/pthread_cond_wait)

I just don't understand how pthread_cond_wait() can be decoupled with the mutex usage.

Hope someone can show me how can it be achieved, Or:
Do I misunderstand the meaning of "decouple" in the comment?

It can be achieved in a cooperative multitasking system, where you have an implicit global mutex. The implicit global mutex is the fact that only one thread runs at a time until it yields the processor. In such a system, you can have condition variables without any explicit mutex in sight. The condition wait operation achieves atomicity by ensuring that the calling thread is prepared for the wait before giving up the processor.

It looks like the text from that manual page is cribbed from the POSIX standard; it appears in the Rationale paragraphs of the description of pthread_cond_wait.

The surest way to determine what anything means in the POSIX standard is to contact the Austin group perhaps by joining the mailing list.

I suspect what this means by "decoupled" is not that a condition not be used without a mutex but that the API somehow allow the application to control the mutex independently, such that waiting on a condition takes multiple steps.

An example of multi-step waiting where the application controls the lock is found in the Linux kernel, in the explicit use of wait queues. To wait on a wait queue, the thread holds some relevant lock. Under that lock, it adds itself to the queue and prepares to wait by changing its state to a sleep state. Then it releases the lock, and calls the scheduler to be suspended. Once past the scheduler call, the thread removes itself from the queue.

There are some advantages to the more complicated, multi-step API, such as being able to register in multiple wait queues. Imagine we had an API pthread_cond_wait_multiple where we specify a mutex, and multiple condition variables, such that the thread wakes up if any of them are broadcast. You can't build that with pthread_cond_wait, but a decoupled API could make it possible.