Why Lock condition await must hold the lock

See the doc for Condition.

A Condition is like a wait pool or wait set of an object and it replaces the use of the Object monitor methods (wait, notify and notifyAll). Conditions enable one thread to suspend execution (to "wait") until notified by another thread that some state condition may now be true. A Condition instance is intrinsically bound to a lock just like the Object monitor methods require the lock of the shared object to wait or notify on. So before invoking await() on a condition, the thread must have locked the Lock object that is used to produce the condition. When the await() method is invoked, the lock associated with the condition is released.

Well, what are we waiting for? We are waiting for a condition to become true. Another thread will make the condition true, then notify the waiting threads.

Before entering wait, we must check that the condition is false; this check and the wait must be atomic, i.e. under the same lock. Otherwise, if we enter the wait while the condition is already true, we'll likely never wakeup.

Therefore it is necessary that the lock is already acquired before calling wait()

synchronized(lock)
{
    if(!condition)
        lock.wait();

If wait() automatically and silently acquires lock, a lot of bugs will go undetected.

---

Upon wakeup from wait(), we must check the condition again -- there's no guarantee that the condition must become true here (for lots of reasons - spurious wakeup; timeout, interruption, multiple waiters, multiple conditions)

synchronized(lock)
{
    if(!condition)
        lock.wait();
    if(!condition)   // check again
        ...

Typically, if the condition is still false, we'll wait again. Therefore the typical pattern is

    while(!condition)
        lock.wait();

But there are also cases where we don't want to wait again.

---

Could there ever be legit use cases where naked wait/notify make sense?

synchronized(lock){ lock.wait(); }

Sure; an application can be made up with naked wait/notify, with well defined behavior; argument can be made that this is the desired behavior; and this is the best implementation for that behavior.

However, that is not the typical usage pattern, and there is no reason to account for it in API design.

Imagine you have something that a thread might need to wait for. Maybe you have a queue and a thread needs to wait until there's something on the queue so it can process it. The queue must be thread-safe, so it has to be protected by a lock. You might write the following code:

1. Acquire the lock.
2. Check if the queue is empty.
3. If the queue is empty, wait for the something to be placed on the queue.

Oops, that won't work. We hold the lock on the queue so how can another thread place something on it? Let's try again:

1. Acquire the lock.
2. Check if the queue is empty.
3. If the queue is empty, release the lock and wait for the something to be placed on the queue.

Oops, now we still have a problem. What if after we release the lock but before we wait for something to be placed on the queue, something is placed on the queue? In that case, we will be waiting for something that already happened.

Condition variables exist to solve this exact problem. They have an atomic "unlock and wait" operation that closes this window.

So await must hold the lock because otherwise there would be no way to ensure you weren't waiting for something that already happened. You must hold the lock to prevent another thread from racing with your wait.

If the thread were merely waiting for a signal to proceed there are other mechanisms for doing that. Presumably there is some state protected by the lock that the thread is waiting to be operated on and satisfy some condition. To properly protect that state the thread should have the lock before and after waiting for the condition, so it makes sense to require acquisition of the lock.