Condition variables are rarely used in Go, because channels are more flexible. I don't think there is much interest in expanding the API used for condition variables. I don't know exactly what you are trying to do, but I suggest that you consider whether you can do it entirely with channels, rather than using a condition variable at all.

In particular, it's very easy to do a blocking FIFO queue of a certain size by using a channel of that size. Then a timed wait, for either adding to the queue or fetching an element from the queue, is simply a select on the queue channel and a time.After channel.

Related: #16620 ("sync: mechanism to select on condition variables")

@ianlancetaylor True.

The only real benefit of Conditions right now is the Broadcast call to notify all waiting clients that they need to check their predicate instead of having to wake up a random one and the put it back to sleep and then try waking up the one waiting for the correct condition that just became true.

The rationale is to give clients consuming the queue more control over their condition/predicate/assertion that they use while they wait for a signal.

The Related: #16620 select on condition variables looks like a good option I think.

/cc @dvyukov

We don't want to increase the API surface of condition variables.