[func25]

The article could be a bit misleading, as it focuses on the act of one goroutine signaling another. That’s why it emphasizes 'for its signaling to work.'

> "In theory, a condition variable like sync.Cond doesn’t have to be tied to a lock for its signaling to work."

It basically separates signaling from lock management, but not about removing the entire need for a mutex. From a pure technical POV, developers can totally handle locking and unlocking the mutex themselves to protect the process of dealing with shared resources, so it's not about technical limitation.

Including a mutex in sync.Cond and having it automatically unlock the mutex in cond.Wait() is an engineering decision that enforces us, developers, to call Lock() on the mutex beforehand and follow the pattern to avoid panic.

[gpderetta]

It is not an engineering decision. There is no way that a thread can safely unlock the mutex before the CV wait without risking missed wake-ups.

The mutex unlock and CV wait must be atomic for the CV to work correctly. There is no way around it.